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Kurzzusammenfassung 


Die wachsende Komplexität moderner Informationssysteme erschwert die 
Nachvollziehbarkeit der Speicherung und Verarbeitung personenbezogener 
Daten. Der einzelne Bürger ist den Systemen quasi ausgeliefert. Das Daten- 
schutzrecht versucht dem entgegenzuwirken. Transparenz, das Recht zu wissen, 
wer was wann und bei welcher Gelegenheit über einen selbst weiß, ist ein 
fundamentales Grundrecht. Ein Werkzeug des Datenschutzes zur Herstellung 
von Transparenz ist der Auskunftsanspruch. Da bisher jedoch eine technische 
Unterstützung für die Erteilung von Auskünften fehlt, erhalten Betroffene meist 
nur statische Datenbankauszüge und keine aussagekräftigen Informationen 
über vergangene Datenerhebungen, Weitergaben und Informationsflüsse. 


Die neuere Forschung arbeitet auf automatisierte Trackingmechanismen für 
personenbezogene Daten hin. Aus der entstehenden Personal-Data-Provenance 
kann dann eine vollständige Datenschutzauskunft abgeleitet und auf einer 
elektronischen Auskunftsplattform bereitgestellt werden. 


Dieses Ziel wurde allerdings noch nicht vollständig erreicht. Die Anforderungen 
des Datenschutzes an eine elektronische Datenschutzauskunft wurden bislang 
nicht ausreichend systematisch berücksichtigt und umgesetzt. Die Struktur 
der Personal-Data-Provenance, deren konfigurierbare, verteilte Erfassung und 
die Zusammenführung der Personal-Data-Provenance zum Zeitpunkt eines 
Auskunftsersuchens sind ungeklärt. Die Datenschutzauskunft und die übrigen 
Betroffenenrechte sind bis dato nicht miteinander verwoben. Die durch die 
zusätzlichen Trackingdaten entstehenden Profilbildungsrisiken automatisierter 
Auskunftssysteme werden nicht adressiert. 


Diese Arbeit unterzieht das Recht auf Auskunft einer kritischen Würdigung als 
Teil des datenschutzrechtlichen Transparenzgedankens und schafft umfassende 
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technische Voraussetzungen fiir die Wahrnehmung des Rechts auf Auskunft. 
Die Beiträge dieser Arbeit sind wie folgt: 


(1) Die Einbindung des Rechts auf Auskunft in die verfassungsrechtliche und 
einfachgesetzliche Struktur des Datenschutzes wird diskutiert. Die Bedeu- 
tung des Auskunftsrechts wird eingeordnet. Die Herausforderungen durch die 
Verabschiedung der Datenschutz-Grundverordnung, insbesondere das Recht 
auf Datenübertragbarkeit, werden mitberücksichtigt. Datenschutzrechtliche 
Anforderungen an eine automatisierte Beantwortung von Auskunftsersuchen 
werden unter Zuhilfenahme eines strukturierten Vorgehensmodells systema- 
tisch abgeleitet. 


(2) Ein verteiltes, datenzentriertes, integriertes und betroffenenfokussiertes 
Datenschutzauskunftssystem wird entworfen und implementiert. Es erlaubt ein 
schichtenunabhängiges, semantisch konfigurierbares Provenance-Tracking über 
Systemgrenzen hinweg. Kombiniert mit Usage-Control-Technologien können 
weitergehende Datenschutzrechte wie der Löschanspruch durchgesetzt werden. 
Die entwickelte Auskunftsplattform erlaubt die interaktive und schrittweise 
Wahrnehmung des Auskunftsrechts. 


(3) Entstehende Profilbildungsrisiken werden mittels einer generischen, instan- 
ziierbaren und berechenbaren Metrik für Unverkettbarkeit, der Unmöglichkeit 
des In-Bezug-Setzens personenbezogener Daten, sichtbar gemacht. Bestehende 
Konzepte für informationstheoretische Unverkettbarkeitsmetriken werden auf 
beliebige Verkettungsrelationen verallgemeinert. Das Schema wird für vier 
Relationen mit Bezug zum entwickelten Datenschutzauskunftssystem instanzi- 
iert. Das A-priori- und A-posteriori-Wissen eines Angreifers wird formalisiert 
und in die Metrik integriert. Die Metrik wird als Grundlage einer infor- 
mierten Entscheidung des Betroffenen bezüglich des Provenance-Trackings 
vorgeschlagen. 


Die Plausibilität des Ansatzes wird anhand eines durchgehenden Beispiels 
gezeigt. Das Datenschutzauskunftssystem wird darüber hinaus auf seine Skalier- 
barkeit hin evaluiert. Die Ergebnisse zeigen, dass eine passgenaue, datenschutz- 
gerechte Datensammlung und eine gute Speicherskalierbarkeit miteinander 
Hand in Hand gehen. Für die Unverkettbarkeitsmetrik wird eine heuristische 
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Berechnung demonstriert. Die Genauigkeit hängt vom Schwellwert des Ab- 
bruchkriteriums ab. Schließlich wird die Akzeptanz der Auskunftsplattform 
durch Nutzer anhand einer Studie gezeigt. Die entwickelte Plattform Priva- 
cyInsight stellt sich gegenüber existierenden Formen der Visualisierung als 
überlegen heraus. 
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Abstract 


The ever-growing levels of complexity of modern information systems com- 
plicate the traceability of processed and stored personal data. The individual 
citizen is at the mercy of the systems. Data protection law tries to counteract 
this. Transparency — the right to know who knows what, when, and on which 
occasion about oneself — is a fundamental right of the German constitution. 
The right to information is one instrument of data protection to establish 
transparency. Since there still is a lack of functionality in regards to transpa- 
rency, the person concerned usually merely receives a static database snapshot. 
Obtaining no meaningful information about collection, transfer, and other flows 
of personal data. 


Recent research efforts evolve around automated tracking mechanisms for 
personal data. All information required can be derived from the resulting 
personal data provenance. This information must be visualized comprehensible 
for the person concerned. 


However, this objective has not yet been fully achieved. The data protection 
requirements for an electronic response to an information request have not yet 
been systematically considered. The data structure of personal data provenance 
is unclear. Its configurable, distributed collection and its aggregation at the 
time of an information request prove to be research gaps. It is an established 
fact that the right to information and other rights of the person concerned have 
not yet been technically interwined. The resulting tracking data raises new 
issues of data protection law itself. They allow extensive profiling which has 
not been addressed. 


In the work at hand the right to information is critically assessed with a focus on 
the notion of transparency. Furthermore, the technical requirements to exercise 
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the right to information are created. The contributions of this work are as 
follows: 


(1) The implementation of the right to information in constitutional and 
legal structures of data protection is examined. The relevance of the right 
to information is evaluated. The challenges arising from the adoption of the 
General Data Protection Regulation, especially the right to data portability, 
are inspected. Data protection requirements for an automated response to 
information requests are systematically derived using a structured approach. 


(2) A distributed, data-centric, integrated and user-focused data protection 
information system is designed and implemented. It allows layer-independent, 
semantic-configurable provenance tracking across system boundaries. Combi- 
ned with usage control, further data protection rights such as the right to erasure 
can be enforced. The implemented privacy dashboard allows the interactive 
and gradual exercise of the right to information. 


(3) Profiling risks are visualized by means of a generic, instantiable and 
calculable metric for unlinkability, the impossibility to interrelate personal 
data. Existing concepts for information-theoretic unlinkability metrics are 
generalized to arbitrary linkage relations. The schema is instantiated for four 
relations related to the data protection information system. A priori and a 
posteriori knowledge of an attacker is formalized and integrated into the metric. 
This metric is proposed as the basis for an informed decision of the person 
concerned regarding the provenance tracking. 


The plausibility of the approach is demonstrated by means of a continuous 
example. In addition, the scalability of the data protection information system 
is evaluated. The results show that a precise data collection and a good memory 
scalability go hand in hand. A heuristic calculation is performed for the 
unlinkability metric. The accuracy depends on the threshold value of the 
termination criterion. Finally, user acceptance of the privacy dashboard is 
verified by a study. The developed platform platform turns out to be superior 
to existing visualizations. 
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1 Einleitung 


Moderne informationstechnische Systeme erreichen eine Komplexität, die 
die Speicherung und Verarbeitung personenbezogener Daten nahezu undurch- 
schaubar macht. Der einzelne Bürger ist den Systemen quasi ausgeliefert. 


Das Datenschutzrecht versucht dem entgegenzuwirken. Transparenz, das Recht 
zu wissen, wer was wann und bei welcher Gelegenheit über mich weiß, ist ein 
fundamentales Grundrecht.” Die Transparenz des Datenumgangs? ist imma- 
nente Voraussetzung des Rechts auf Informationelle Selbstbestimmung. Ohne 
sie wird ein besonnener und rücksichtsvoller Einsatz von Informationstechno- 
logie (IT) nicht sichtbar, eine Intervention in die Verarbeitungsvorgänge nicht 
möglich. * 


Ein Werkzeug des Datenschutzes zur Herstellung von Transparenz ist der 
Auskunftsanspruch. Er ist Voraussetzung zur Wahrnehmung der übrigen Be- 
troffenenrechte auf Löschung, Sperrung und Berichtigung. Trotz seiner enormen 
Bedeutung für einen effektiven Datenschutz wird der Auskunftsanspruch durch 
die Praxis vernachlässigt. Auskünfte werden zwar erteilt, jedoch nur in Form 
von statischen Datenbankauszügen,° auch wenn diese ausgesprochen umfang- 
reich ausfallen können.® Dem liegt nicht unbedingt ein Unwille der beteiligten 
Stellen zu Grunde. Die fragmentierte Informationsverarbeitung, innerhalb und 


' Masing, NJW 2012, 2305 (2308); Weichert, DuD 2006, 694 (695). 

2 BVerfGE 65, 1 (43); BVerfGE 125, 260 (334). 

3 Die Begriffe „Datum“, „Information“, „Umgang“, „Verwendung“, „Verarbeitung“, „Nutzung“ 
usw. werden im Glossar am Ende der Arbeit erklärt. 

4 BVerfGE 65, 1 (43). 

5 Mehr dazu im Abschnitt 1.1.1. 

6 Beispielsweise die von Facebook bereitgestellten Datenbestände — zu finden unter http://www. 
europe-v-facebook.org/DE/Datenbestand/datenbestand.html, abgerufen am 9. Mai 2017. 
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auBerhalb standardisierter Prozesse, erschwert oder unterbindet das Zusam- 
mentragen von Informationen tiber vergangene Datenerhebungen, Weitergaben 
und Informationsfltisse. Eine technische Realisierung des Rechts auf Auskunft 
wurde bisher unzureichend angegangen. ! 


An dieser Stelle setzt Personal-Data-Provenance an. Personal-Data-Provenance 
ist die dokumentierte Historie eines personenbezogenen Datums. Eine 
Provenance-Tracking-Infrastruktur verfolgt demnach den Lebenszyklus eines 
personenbezogenen Datums ausgehend von der Erhebung beim Betroffenen 
oder einem Dritten, tiber einzelne Verarbeitungs- und Speicherschritte bis hin 
zur Ubermittlung. Personenbezogene Daten werden bei der Erhebung annotiert 
und der Umgang mit ihnen fortlaufend und automatisiert protokolliert. Alle 
Schritte werden mit dem Zweck der Erhebung und Verarbeitung des perso- 
nenbezogenen Datums in Bezug gesetzt. Letztendlich soll der Betroffene die 
Möglichkeit bekommen, über eine Auskunftsplattform jederzeit Einblick in 
den Umgang mit seinen personenbezogenen Daten zu nehmen. 


Kombiniert mit Usage-Control-Technologien können weitergehende Daten- 
schutzrechte, wie der Löschanspruch, im Nachhinein direkt über die Auskunfts- 
plattform durchgesetzt werden. Auf der anderen Seite können die entstehenden, 
stark verknüpften Trackingdaten auch selbst neue datenschutzrechtlichen Pro- 
bleme aufwerfen. Sie leisten einer umfangreichen und freiheitsgefährdenden 
Profilbildung Vorschub. In diesem Spannungsfeld und unter Berücksichtigung 
eines sich wandelnden und europäisierenden Datenschutzes stellt diese Arbeit 
ein integriertes Datenschutzauskunftssystem vor. 


1.1 Motivation 


In unserer Gesellschaft besteht kein Konsens mehr, was öffentlich und was privat 
ist.” Die Wertschätzung personenbezogener Daten variiert stark. Die einen 


! Wachter, DuD 1996, 272 (273). 
2 Masing, NJW 2012, 2305 (2308). 
3 Grossklags/Acquisti 2007; Beresford/Preibusch/Kübler 2010; Acquisti/John/Loewenstein 2013. 
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pflegen den digitalen Exhibitionismus, die anderen streben einen neuen Grad der 
Anonymität an. Nutzer digitaler Dienste werden entsprechend ihrer Einstellung 
zum Umgang mit personenbezogenen Daten in Datenschutzfundamentalisten, 
Pragmatiker, und Unbekümmerte eingeteilt. ! In Studien wurde festgestellt, dass 
zusätzlich zur gesellschaftlichen Vielfalt auch das Verhalten des Einzelnen nicht 
konsistent ist. Behauptete Präferenzen und tatsächliches Verhalten weichen 
voneinander ab.” Das Verhalten selbst ist nicht konsistent im Hinblick auf 
die zu erwartenden Konsequenzen? und stark abhängig von kontextuellen, 
nicht-normativen Faktoren. 4 


Der Auskunftsanspruch ist von all dem unabhängig.° Das Recht auf informa- 
tionelle Selbstbestimmung ist universell und kann nicht durch ein bestimmtes 
Verhalten des Betroffenen verwirkt werden. Es wirkt grundsätzlich in alle 
Branchen und Anwendungsdomänen hinein.” Besondere Arten personenbezo- 
gener Daten, wie Gesundheitsdaten und politische oder religiöse Zugehörigkeit, 
sind genauso geschützt wie Alltägliches und Triviales. 


Insofern ergibt sich der Bedarf für ein integriertes Datenschutzauskunfts- 
system nicht aus einem bestimmten Geschäftsmodell, sondern aus seiner 
rechtlichen Relevanz. Welche offenen Forschungsfragen existieren oder ob die 
Anforderungen des Datenschutzes auch ohne ein Datenschutzauskunftssystem 
schon heute erfüllt werden, klärt der folgende Abschnitt. 


' Kumaraguru/Lorrie F. Cranor 2005. 

? Berendt/Günther/Spiekermann 2005. 

3 Woodruff et al. 2014. 

4 Acquisti/John/Loewenstein 2013. 

5 Siehe Kapitel 3.4. 

6 Auch wenn Daten aus allgemein zugänglichen Quellen entnommen werden können, sieht das 
BDSG keine Ausnahme von der Auskunftspflicht vor — zur einschlägigen Auslegung von § 34 
Abs 7 i. V. m. § 33 Abs. 2 S. 2 Nr. 7 siehe Kapitel 3.8.3. 

7 Siehe allerdings Kapitel 2.1.2 zur Problematik der Drittwirkung der Grundrechte. 
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1.1.1 Status Quo des Auskunftsrechts in der Praxis 


Zu Beginn des Jahrtausends war es um die Situation des Auskunftsanspruchs 
schlecht bestellt. Noch im Jahr 2005 hat die SCHUFA Auskunftsersuchen 
merkblattartig beantwortet.! Neben einer fehlenden oder nicht rechtzeitigen 
Reaktion auf ein Auskunftsersuchen waren die Auskünfte häufig unvollständig 
oder hatten rein beschreibenden Charakter, so der ehemalige Leiter des Unab- 
hängigen Landeszentrums für Datenschutz Schleswig-Holstein (ULD), Thilo 
Weichert, im Jahre 2006.” 


Auch 2012 war das unabdingbare Recht auf Auskunft noch vielen Unternehmen 
unbekannt. Sein Umfang wurde unterschätzt oder schlicht ignoriert. Anfragen 
wurden nicht oder nur unvollständig beantwortet. Insbesondere Adresshändler 
waren nicht bereit, Informationen über Datenempfänger so genau mitzuteilen, 
dass sie von Betroffenen genutzt werden konnten. Die wesentlichen Gründe 
waren komplexe Unternehmensstrukturen, mangelhafte technische und or- 
ganisatorische Voraussetzungen und fehlendes Wissen über die rechtlichen 
Anforderungen.’ 


In den aktuellen Berichten der Landesbeauftragten für den Datenschutz (LfD) 
erscheint die Situation nur unwesentlich besser. Unternehmen geben teilweise 
immer noch unzureichend oder keine Auskunft.* Begründet in einer extrem 
niedrigen Kontrolldichte,° ist die Berichtsdichte der LfD zum Auskunftsan- 
spruch insgesamt gering. 


Eine Erhebung im Rahmen einer DFG-Studie zum TMG ergab im Jahr 2009 eine 
Rücklaufquote von 54 % auf Auskunftsersuchen.® Ein erster unstrukturierter 
Versuch, Auskünfte inhaltlich zu analysieren, wurde im Rahmen des EU- 
Forschungsprojektes Increasing Resilience in Surveillance Societies (IRISS) 


1 LfD Hessen, 34. Tätigkeitsbericht, LT-Drs. 16/5892, 13. 
2 Weichert, DuD 2006, 694 (694). 

3 LED Hessen, 41. Tätigkeitsbericht, 184 ff. 

4 LfD Brandenburg, 18. Tätigkeitsbericht, 164 f. 

> Schulzki-Haddouti 2016, 114 ff. 

6 Kühling et al., DuD 2009, 335 (342). 
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unternommen.! Umfangreichere Untersuchungen wurden jedoch erst in den 
Jahren 2015/16 durchgefiihrt. 


Die Untersuchung von Herrmann und Lindemann nahm zwei verschiedene 
Bereiche in den Blick.” Im ersten Teil wurden die 100 populärsten Smartphone- 
Apps in Deutschland, 50 fiir das Googles Android-Betriebssystem und 50 fiir 
Apples iOS, installiert und genutzt. Anschließend wurde bei den Anbietern der 
Apps eine Auskunftsanfrage gestellt. Von den 100 Anfragen wurden 43 % im 
Großen und Ganzen ordnungsgemäß beantwortet. Für die deutschen Anbieter 
lag die Quote immerhin bei 75%. 12% aller Anbieter beantworteten die 
Anfrage nur auf abstrakte Art und Weise oder offensichtlich unvollständig. Die 
übrigen Anbieter antworteten entweder gar nicht, waren nicht erreichbar oder 
verweigerten die Auskunft. 


Im zweiten Teil wurde eine Stichprobe von 120 der 500 beliebtesten Webseiten’ 
in Deutschland (davon 57 aus den Top 100) ausgewählt. Auf diesen Webseiten 
wurde ein Benutzeraccount mit einer E-Mailadresse angelegt. Auch an die 
Webseitenbetreiber wurde anschließend ein Auskunftsersuchen gerichtet. Der 
Anteil der ordnungsgemäßen Antworten lag wieder bei 43 %, die der unvoll- 
ständigen bei 16 %. Ergänzend wurden auch Anfragen von nicht registrierten 
E-Mailadressen gestellt. Der Umgang mit diesen Anfragen war beunruhigend. 
In immerhin 18 % der Fälle wurden personenbezogene Daten mitgeteilt, ohne 
die Berechtigung zu prüfen. Dies lässt auf unzureichende Identifikationsprozes- 
se bei den jeweiligen Unternehmen schließen. Dritte können so leicht Zugang 
zu sensiblen personenbezogenen Daten erhalten. 


Die eigens erstellte,* zeitgleiche Studie bestand aus einem quantitativen und 
einem sich anschließenden qualitativen Teil. Sie ist detailliert in Anhang A 
beschrieben. 


Im qualitativen Teil wurde die Reaktion von 40 ausgewählten Unternehmen auf 
Auskunftsersuchen ausgewertet. Die Prüfung der Auskünfte erfolgte entlang 


! Zurawski 2014. 

? Herrmann/Lindemann 2016. 

3 Alexa top 500 sites on the web, Germany, http://www.alexa.com/topsites/countries/DE. 
4 Bier/Kémpf/Beyerer 2017. 
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Abbildung 1.1: Erfüllungsgrad der Anforderungen durch die erteilten Auskünfte 


der zwölf in Tabelle A.2 des Anhangs aufgelisteten Anforderungen. Die 
Anforderungen teilen sich in drei formale (# 1-3) und neun inhaltliche (# 4-12) 
Anforderungen auf. 


Abbildung 1.1 zeigt den Erfüllungsgrad der Anforderungen durch die erteilten 
Auskünfte. Die Situation bei den formalen Kriterien liegt im akzeptablen 
Bereich. Bis auf ein Unternehmen konnten alle auf irgendeine Art und Weise 
kontaktiert werden. 27 Unternehmen (67,5 %) beantworteten die Auskunfts- 
anfrage in weniger als 15 Tagen. Nur sechs Unternehmen stellten auch nach 
6 Monaten noch keine Auskunft zur Verfügung. Alle Auskünfte bis auf zwei 
waren klar strukturiert und verständlich formuliert. 


Die Lage bei den inhaltlichen Kriterien fällt deutlich schlechter aus. Insbeson- 
dere Angaben zu Speicherort, Empfängern, Datenflüssen und dem Zweck der 
Speicherung sind unvollständig. Der Speicherort wurde meist dann sichtbar, 


1.1 Motivation 


wenn Screenshots von Datenbankanwendungen als Teil der Auskunft mitgelie- 
fert wurden. Dies war immerhin bei sechs Unternehmen der Fall. Die internen 
Fliisse personenbezogener Daten wurden in keinem Fall voll zufriedenstellend 
wiedergegeben. Nur wenige Auskünfte beinhalten überhaupt Angaben dazu. 
Positive Ausnahme war ein deutscher Versand- und Einzelhändler, der grundle- 
gende Informationen zu den an der Datenverarbeitung beteiligten Abteilungen 
mitlieferte. Er stand auch insgesamt mit 11 erfüllten oder teilweise erfüllten 
Anforderungen an der Spitze. 


Einen Überblick über die Belastung der Unternehmen durch Auskunftsanfragen 
bietet die 2bAdvice-Studie zur Datenschutzpraxis.! Die 272 befragten Unter- 
nehmen erhalten im Durchschnitt 231 Auskunftsersuchen jährlich. Allerdings 
ist die Belastung durch Auskunftsersuchen stark ungleich verteilt. 100 von 
ihnen haben noch nie ein Auskunftsersuchen erhalten und nur 14 % erhalten 
über 100 Anfragen pro Jahr. Die Anzahl der Auskunftsanfragen nimmt mit der 
Unternehmensgröße zu. 


Die Hauptlast der Auskunftsanfragen tragen wenige große oder exponierte 
Unternehmen wie Auskunfteien, Handelsunternehmen oder Unternehmen, 
die bereits wegen Datenschutzthemen im Medienfokus standen.” Bei einem 
Versandhändler mittlerer Größe sind im Kundenservice etwa 1,5 vollzeitäqui- 
valente Stellen für die Beantwortung von Auskuftsersuchen vorgesehen. Bei 
einem großen Logistikkonzern mit über 100 Mitarbeitern im Datenschutz ist, 
zusätzlich zu einem großen Kundenservice, ein spezialisierter Mitarbeiter in 
Vollzeit mit der Bearbeitung von Auskunftsersuchen beschäftigt. Ein anderes 
exponiertes Unternehmen ist die Deutschen Telekom AG. Bei ihr arbeiten 63 
Mitarbeiter in Vollzeit am Thema Datenschutz.’ 


Insgesamt ergibt sich ein Bild des Status quo der Datenschutzauskunft, der 
Forschungsanstrengungen im Hinblick auf ein integriertes Datenschutzaus- 
kunftssystem in zwei Dimensionen rechtfertigt. Zum einen, um die Einhaltung 


! Malinka et al. 2015. 
? Die folgenden Daten entstammen vertraulichen Expertengesprächen. 
3 Schulzki-Haddouti 2016, 117. 
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datenschutzrechtlicher Anforderungen, insbesondere im Hinblick auf Informati- 
onsflüsse, zu verbessern. Zum anderen, um durch eine stärkere Automatisierung 
die Belastung der Unternehmen zu reduzieren. 


1.1.2 Bestehende Ansätze zur elektronischen 
Auskunftserteilung in Literatur und Praxis 


Datenschutzauskunftssysteme sind im größeren Kontext von Transparency En- 
hancing Technologies (TETs) zu sehen. Eine umfangreiche Bestandsaufnahme 
zu diesem Forschungsfeld findet sich in den Veröffentlichungen von Hedbom! 
sowie Janic et al.” 


Eine generelle Klassifikation gegenwärtiger und zukünftiger Privacy Dash- 
boards wurde von Zimmermann et al. entwickelt.’ 


Hilfestellungen für den Betroffenen, die allerdings das Recht auf Auskunft nicht 
ersetzen können, sind Browser-Plug-Ins wie Mozilla Lightbeam.* Lightbeam 
deckt die Abhängigkeit des Cookie-Trackings durch unterschiedliche Parteien 
auf Clientseite auf. 


Das Data Disclosure Log von Kolter et al. setzt gleichermaßen auf einer 
Browser-Erweiterung auf.” Es ist eine Java-Applikation, die Datenverarbei- 
tungsvorgänge in verschiedenen graphenbasierten Sichten darstellbar macht. 
Zusätzlich zu dem aus den Browserdaten entnommenen Verhalten des Betrof- 
fenen greift das Data Disclosure Log auf eine „Crowd-Sourced“-Datenbank 
zu, die Informationen zu den weiteren Datenverarbeitungsvorgängen bei der 
verantwortlichen Stelle enthält. 


Standardisierte Bildsymbole (Privacy Icons) können ebenfalls als Hilfsmittel für 
zukünftige Auskunftsplattformen gesehen werden. Mit ihnen können der Zweck 


' Hedbom 2009. 

2 Janic/Wijbenga/Veugen 2013. 

3 Zimmermann/Accorsi/Müller 2014. 

4 https://www.mozilla.org/de/lightbeam. 
5 Kolter/Netter/Pernul 2010. 


1.1 Motivation 


der Datenverarbeitung und Richtlinien zum Umgang mit personenbezogenen 
Daten visualisiert werden. Ein Überblick über Forschungsanstrengungen in 
dieser Richtung wurde von Hansen verfasst.! Standardisierte Bildsymbole 
werden durch ihre Verankerung in Art. 12 Abs. 7 DSGVO in Zukunft noch an 
Bedeutung gewinnen.” 


Das Forschungsprojekt „Datenschutz-Auskunftsportal“ konzipierte eine zen- 
trale Plattform, die Betroffene darin unterstützt, ihr Recht auf Auskunft 
wahrzunehmen. Neben allgemeinen Informationen sollte die Plattform ei- 
ne prozessgestützte Hilfe zur Einreichung von Auskunftsersuchen bieten.? Zu 
den Ergebnissen des Projektes auf technischer Seite ist bisher wenig bekannt. 
Schon seit längerer Zeit verfügbar ist die Formularhilfe selbstauskunft.net. 
Sie unterstützt die teilautomatisierte Anforderung von Auskünften bei 1786 
Unternehmen und Behörden.* 


Plattformen wie das Google Privacy Dashboard und das Portal von acxiom® 


bieten neben der Einstellung von Datenschutzpräferenzen auch die Möglich- 
keit, Einblick in bestimmte personenbezogene Daten zu nehmen. Sie sind das, 
was heute einer Datenschutzauskunftsplattform am nächsten kommt. Aller- 
dings erfüllen auch diese Tools nicht alle im letzten Abschnitt eingeführten 
Anforderungen. Insbesondere werden Herkunft und Empfänger von personen- 
bezogenen Daten nicht vollumfänglich dargestellt. Der Zweck ist nicht entlang 
der stattfindenden Verarbeitungsprozesse erkennbar. 


Das umfangreichste Projekt, das sich in den letzten Jahren mit technischen 
Lösungen für Datenschutzauskunftssysteme auseinandergesetzt hat, war das 
EU-Forschungsprojekt Accountability For Cloud and Other Future Internet 


! Hansen 2009. 

? Weitere Ideen finden sich bei Holtz/Nocun/Hansen 2011 und Fischer-Hübner/Köffel et al. 2010. 
3 ULD Schleswig-Holstein, 35. Tätigkeitsbericht, LT-Drs. 18/2730, 121. 

4 https://selbstauskunft.net/unternehmen, abgerufen am 9. Mai 2017. 

5 https://www.google.com/dashboard. 

6 https://aboutthedata.com/portal. 
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Services (A4Cloud)! mit seinen beiden Vorgängerprojekten Privacy and Iden- 
tity Management for Europe (PRIME)? und Privacy and Identity Management 
in Europe for Life (PrimeLife).? Das Projekt A4Cloud entwickelte eine Archi- 
tektur fiir die Beschreibung und Durchsetzung von Datenschutz-Policies in der 
Cloud, die Protokollierung und Auditierung der Datenverarbeitung in der Cloud, 
sowie die Benachrichtigung des Betroffenen tiber die Datenverarbeitungsvor- 
gänge. A4Cloud sieht jedoch kein, in einer durchgängigen und vollständigen 
Provenance resultierendes, systemiibergreifendes Informationsflusstracking 
vor. 


Die Software Data Track war eines der ersten Tools um Transparenz tiber 
die Erhebung von personenbezogenen Daten beim Betroffen zu schaffen.* 
Urspriinglich war Data Track ein clientseitiges Transaktionsprotokoll fiir 
personenbezogene Daten. Darauf aufbauend wurde das Werkzeug im Rahmen 
der drei Forschungsprojekte fortlaufend weiterentwickelt. In A4Cloud wurde es 
integraler Bestandteil der serverseitigen Transparenzplattform für die Cloud, ° 
genannt GenomSynlig.® 


GenomSynlig bietet zwei Ansichten auf vergangene Datenerhebungen, den 
„Trace View“ und den „Timeline View“.’ Ersteres ist eine graphenbasierte An- 
sicht auf die Verknüpfungen zwischen Daten und erhebenden Stellen. Letzteres 
ist eine Zeitleiste, inspiriert durch Darstellungen wie die Facebook Chronik. 8 
Sie zeigt Erhebungen personenbezogener Daten in chronologischer Reihenfol- 
ge. Da GenomSynlig Cloud-basiert ist, liegt die Hauptlast für die Herstellung 
der Transparenz beim Cloudanbieter, also einem Auftragsdatenverarbeiter, statt 
bei der verantwortlichen Stelle. GenomSynlig liefert nur Informationen, wenn 
der Betroffene die Quelle der personenbezogenen Daten ist. Das Tool bietet 
keine Informationen über Datenflüsse innerhalb der verantwortlichen Stelle 


U http://www.a4cloud.eu. 

? https://www.prime-project.eu. 

3 http://primelife.ercim.eu. 

4 Wästlund/Fischer-Hübner et al. 2010. 

5 Fischer-Hiibner/Angulo/Pulls 2014; H. Andersson et al. 2015. 

6 http://hci.cse.kau.se:8000. 

7 Angulo et al. 2015. 

8 https://www.facebook.com/help/2507 14824948501, abgerufen am 9. Mai 2017. 


10 


1.1 Motivation 


oder zu Ubermittlungen nach außen. Empfänger personenbezogener Daten 
sind nicht sichtbar. Auch der Zweck kann nicht mit den unterschiedlichen 
Verarbeitungsschritten in Bezug gesetzt werden. Die in A4Cloud entwickelten 
Technologien würden zumindest konzeptionell erlauben, auch andere Schritte 
der Datenverarbeitung zu erfassen. Mit der Accountable PrimeLife Policy 
Language (A-PPL) ist eine Beschreibungssprache für Logging-Policies vor- 
handen.! Insynd, eine weitere Komponente aus A4Cloud, ist als serverseitiges 
Transaktionsprotokoll geeignet.” 


Ein anderes Werkzeug, das einer Auskunftsplattform nahekommt, ist das 
interaktive Online-Tool, genannt Translucene Map, von Kani-Zabihi und 
Helmhout.? Es visualisiert den Fluss personenbezogener Daten in allgemeiner 
Form, d.h. auf Grundlage des Verfahrensverzeichnisses, nicht auf Grundlage 
tatsächlich stattfindender Datenflüsse. Der Betroffene ist in der Lage, den Fluss 
verschiedener Datenkategorien im dargestellten Graphen hervorzuheben und 
nachzuverfolgen. 


Insgesamt ist es mit keinem der vorgestellten Ansätze möglich, eine vollständige 
Datenschutzauskunft automatisiert bereitzustellen. Die Anforderungen des 
Datenschutzes werden nicht systematisch berücksichtigt. Die Struktur der 
Personal-Data-Provenance, deren konfigurierbare, verteilte Erfassung und 
die Zusammenführung der Personal-Data-Provenance zum Zeitpunkt eines 
Auskunftsersuchens sind ungeklärt. Die Datenschutzauskunft und die übrigen 
Betroffenenrechte sind nicht miteinander verwoben. Die Profilbildungsrisiken 
automatisierter Auskunftssysteme werden nicht adressiert. 


! Butin/Chicote/Métayer 2013. 
2 Pulls/Peeters 2015. 
3 Kani-Zabihi/Helmhout 2012. 
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1.2 Zielsetzung 


Die vorliegende Arbeit soll die technischen Voraussetzungen für die Wahr- 
nehmung des Rechts auf Auskunft schaffen und das Recht auf Auskunft 
einer kritischen Würdigung als Teil des datenschutzrechtlichen Transparenz- 
gedankens unterziehen. Insbesondere soll auf das Spannungsfeld zwischen 
Unverkettbarkeit, der Unmöglichkeit des In-Bezug-Setzens personenbezogener 
Daten,! und Transparenz eingegangen werden. 


Technisch soll eine Plattform entwickelt werden, die Datenflüsse transparent 
macht, Personal-Data-Provenance bereitstellt, die Interventionsrechte des Be- 
troffenen integriert und gleichzeitig das Verbot der Verkettung und Profilbildung 
beachtet. 


Juristisch sollen die datenschutzrechtlichen Implikationen eines Datenschutz- 
auskunftssystems als zentrale rechtliche Problemlage beleuchtet werden. Dies 
umfasst sowohl die präzise Herausarbeitung von Anforderungen, als auch 
deren Bewertung. Grundlage ist eine nähere Auseinandersetzung mit dem 
datenschutzrechtlichen Auskunftsanspruch und der Einbindung der Transparenz 
in die datenschutzrechtliche Systematik. 


Im Mittelpunkt steht der Betroffene als Auskunftsberechtigter. Seine Ent- 
scheidungsfreiheit soll gestärkt, Wahlmöglichkeiten auf Grundlage fundierter 
Informationen geschaffen werden. 


Das Ziel dieser Arbeit ist die Definition, Formalisierung und Im- 
plementierung technischer Voraussetzungen für die Wahrneh- 
mung des Rechts auf Auskunft und dessen kritische Würdigung 
als Teil des datenschutzrechtlichen Transparenzgedankens. 


! ULD/TU Dresden 2007, 19 £. 
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1.2.1 Forschungsfragen 


„Das Auskunftsrecht ist für die Betroffenen das fundamentale Datenschutz- 
recht.“! Aus diesem Grund sollen in dieser Arbeit die verfassungsrechtlichen, 
europarechtlichen und einfachgesetzlichen Bestimmungen, die das Recht auf 
Auskunft stützen, identifiziert, analysiert und kritisch beleuchtet werden. 


Wie ist das Recht auf Auskunft in die Gesamtkonzeption des Datenschutzes 
eingebunden und welche Anforderungen und Konsequenzen ergeben sich 
daraus? 


e Wie ist das Recht auf Auskunft verfassungsrechtlich und europarechtlich 
verankert? 


e Wie ist das Recht auf Auskunft in das dreistufige Schema aus datenschutz- 
gerechter Verarbeitung, Transparenz und Intervention eingebunden? 


e Welche Reichweite und welchen Umfang hat der Auskunftsanspruch? 


e Wie können (datenschutz-)rechtliche Anforderungen systematisch abge- 
leitet und in technische Anforderungen überführt werden? 


e Wie sehen die datenschutzrechtlichen Anforderungen an ein Daten- 
schutzauskunftssystem aus? 


Das Auskunftsrecht steht nicht alleine. Es ist die Voraussetzung zur Wahrneh- 
mung der übrigen Betroffenenrechte auf Löschung, Sperrung und Berichtigung. 
Deshalb ergänzen sich Provenance-Tracking und Nutzungskontrolle in der 
Erreichung der durch das Datenschutzrecht gestellten Anforderungen.” Eine 
Herausforderung dieser Arbeit ist der Entwurf einer integrierten Architek- 
tur für Provenance-Tracking und Nutzungskontrolle, deren Modellierung und 
Implementierung in einem Prototypen. 


! Neben anderen: Dix in: Simitis, BDSG 2014, § 34 Rn. 1. 
? Bier 2013b. 
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Wie sieht eine generische Architektur und ein Modell fiir ein integriertes 
Datenschutzauskunftssystem aus, das die datenschutzrechtlichen Anforde- 
rungen erfüllt und technisch umsetzbar ist? 


e Wie sieht eine verteilte, gemeinsame Architektur von Provenance- 
Tracking und Usage-Control aus? 


e Wie kann eine nahtlose Kette Erhebung — Verarbeitung — Transparenz 
— Intervention durch Provenance-Tracking und Usage-Control erreicht 
werden? 


e Wie kann Personal-Data-Provenance datenminimal, dem Anwendungsfall 
angemessen und hinreichend präzise erfasst und gespeichert werden? 


e Wie kann Personal-Data-Provenance so präsentiert und visualisiert 
werden, dass sie den rechtlichen Anforderungen und den Bedürfnissen 
der Betroffenen gerecht wird? 


Personal-Data-Provenance ermöglicht Transparenz, führt aber gleichzeitig 
dazu, dass die Menge und Aussagekraft der erhobenen personenbezogenen 
Daten deutlich steigt. Dies mag zwar dem Auskunftszweck dienlich sein, stellt 
aber auch selbst einen Eingriff dar. Es werden Datenverknüpfungen hergestellt, 
die ohne Provenance-Tracking nicht bestünden. Diese Arbeit soll den genannten 
Konflikt beleuchten und Lösungsansätze unter Einbeziehung des Betroffenen 
aufzeigen. 


Wie lassen sich Transparenz und Unverkettbarkeit, unter Berücksichtigung 
des individuellen Betroffenen, in Einklang miteinander bringen? 


e Wie lässt sich Unverkettbarkeit formal beschreiben? 
e Wie kann Unverkettbarkeit analytisch bestimmt und berechnet werden? 


e Zu welchem Grad wird die Architektur des entworfenen Datenschutz- 
auskunftssystems dem Ziel der Unverkettbarkeit gerecht? 


e Wie kann der Betroffene in den Abwägungsprozess zwischen Transparenz 
und Unverkettbarkeit einbezogen werden? 
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Die genannten Forschungsfragen fiihren, unter Beriicksichtigung des Ziels 
dieser Arbeit und unter Einbeziehung bereits existierender Forschungsansat- 
ze, zu den im nächsten Abschnitt aufgeführten Forschungshypothesen und 
Konstruktionszielen. 


1.2.2 Forschungshypothesen und Konstruktionsziele 


Die folgenden Forschungshypothesen § und Konstruktionsziele A struktu- 
rieren diese Arbeit. Sie werden in den einzelnen Kapiteln aufgegriffen und 
korrespondieren mit diesen. Die Hypothesen sind vorab getroffene Annahmen 
zu wissenschaftlichen Fragestellungen, die im Rahmen dieser Arbeit be- oder 
widerlegt werden. 


Hı Das Recht auf Auskunft ist im Grundgesetz und in der Charta als 
unabdingbares Betroffenenrecht verankert. 


%2 Der Betroffene hat das Recht, den Fluss seiner personenbezogenen Daten 
vollständig nachvollziehen zu können. 


§3 Die anvisierte Implementierung von Provenance-Tracking ist datenmini- 
mal und skalierbar. 


94 Es ist rechtlich zulässig und technisch möglich, den Betroffenen anhand 
einer Metrik für Unverkettbarkeit informiert entscheiden zu lassen, ob 
ihm eine umfangreiche Auskunft und das Recht auf Datenübertragbarkeit 
oder die Unverkettbarkeit seiner personenbezogenen Daten wichtiger 
sind. 


§5 Eine Datenschutzauskunftsplattform, die Flüsse personenbezogener 
Daten interaktiv darstellen kann, ist nutzerfreundlicher und verständlicher 
als bestehende Systeme zur Datenschutzauskunft. 


Die Konstruktionsziele legen das gewünschte Ergebnis der systematischen 
Entwicklung von Modellen, Architekturen und Systemen für das Datenschutz- 
auskunftssystem fest. Die gesetzten Ziele werden von den bereits bestehenden 
Ansätzen aus Literatur und Praxis nicht erreicht. 
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Kı 


R3 


85 


R6 


1.3 


Ein Modell zur systematischen Ableitung technischer Anforderungen 
an die Implementierung eines Datenschutzauskunftssystems aus den 
Datenschutz-Schutzzielen und den datenschutzrechtlichen Anforderun- 
gen 


Eine verteilte, generische Architektur für ein Datenschutzauskunftssys- 
tem, die die Durchsetzung von Transparenz und Intervenierbarkeit in 
einem gemeinsamen System erlaubt 


Die Erhebung und Speicherung von Personal-Data-Provenance in einem 
Datenmodell gemäß der datenschutzrechtlichen Anforderungen 


Die verteilte Speicherung und systemübergreifende Erhebung von 
Personal-Data-Provenance, die im Sinne einer informationellen Gewal- 
tenteilung erst zum Anfragezeitpunkt aggregiert und an den Betroffenen 
kommuniziert wird 


Eine berechenbare Metrik zur Messung von Unverkettbarkeit in den durch 
die datenschutzrechtlichen Anforderungen vorgegebenen Dimensionen 


Der Entwurf eines Datenschutzauskunftssystems unter Berücksichtigung 
aller datenschutzrechtlichen Anforderungen 


Lösungsstrategie 


Der interdisziplinäre Charakter dieser Arbeit erfordert je nach Themen- 
und Fachbereich unterschiedliche Lösungsstrategien für die Bewälti- 
gung der aufgeworfenen Herausforderungen. Rechtswissenschaftliches und 
informationstechnisch-ingenieurwissenschaftliches Arbeiten werden miteinan- 
der verwoben. 


Die Analyse der verfassungsrechtlichen, europarechtlichen und einfachge- 
setzlichen Verankerung des Rechts auf Auskunft wird durch die rechtswis- 
senschaftliche Auseinandersetzung mit der maßgeblichen Fachliteratur und 
Rechtsprechung geprägt. Bestehende Ansätze werden eingeordnet und kritisch 
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reflektiert, Perspektiven werden zusammengeführt und neue Schlussfolge- 
rungen werden gezogen. Reichweite und Umfang des Rechts auf Auskunft 
werden diskutiert, Anforderungen an ein Datenschutzauskunftssystem werden 
abgeleitet. Dabei werden die aufgestellten Hypothesen im Blick behalten und 
kritisch beleuchtet. 


Die datenschutzrechtlichen Anforderungen bilden die Brücke zwischen rechts- 
wissenschaftlichem und informationstechnisch-ingenieurwissenschaftlichem 
Teil. Ein in der rechtswissenschaftlichen Literatur etabliertes Ableitungsmodell 
wird angepasst und so verfeinert, dass eine durchgängige Ableitungskette 
von den Grundrechten bis zur Implementierung möglich wird. Die rechts- 
wissenschaftliche Anforderungsanalyse wird mit Ansätzen des Requirements- 
Engineering in Deckung gebracht. Die sich aus rechtlichen Kriterien ergebenden 
technischen Anforderungen dienen als Blaupause für die Spezifikation von 
Datenmodellen, Schnittstellen und den informationstechnischen Architektur- 
entwurf des Datenschutzauskunftssystems. 


Die Verbindung von Provenance-Tracking und Usage-Control wird im Modell 
und anhand eines Prototyps erarbeitet. Eine gemeinsame Architektur wird 
unter Beachtung bestehender Ansätze in der Data-Provenance- und Usage- 
Control-Fachliteratur entworfen. Dabei gelten die abgeleiteten Anforderungen 
als Leitplanke für den Entwurf. Um Usage-Control und Provenance-Tracking 
zu verbinden, wird das bestehende UC-Informationsflussmodell! um ein 
Provenance-Datenmodell erweitert. Bisherige generische Ansätze zur Model- 
lierung von Data-Provenance” werden für den Anwendungsfall Datenschutz- 
auskunft instanziiert und unter Einbeziehung des UC-Informationsflussmodells 
formalisiert. 


Personal-Data-Provenance muss datenminimal, dem Anwendungsfall angemes- 
sen und hinreichend prazise vorgehalten werden. Problematisch ist insbesonde- 
re, dass der Speicherbedarf von Provenance bei naivem Vorgehen superlinear 
wächst (schlechte Speicherskalierbarkeit). Deshalb werden Ansätze verfolgt, 
die die Größe der Provenance im Verhältnis zur Menge der in jedem Schritt 


! Pretschner/Lovat/Büchler 2011. 
2 Moreau/Clifford et al. 2011. 
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verarbeiteten personenbezogenen Daten maximal linear und im Verhältnis 
zur Menge der Operationen sublinear steigen lassen. Dies wird anhand eines 
Prototyps für das Betriebssystem Windows 7 evaluiert. 


Personal-Data-Provenance muss über Systemgrenzen hinweg aufgezeichnet 
und zum Abfragezeitpunkt aggregiert werden. Deshalb wird das kombinierte 
Informationsfluss- und Provenancemodell zum systemübergreifenden Tracking 
ertüchtigt. Zu diesem Zweck wird das schichtenübergreifende Informations- 
flussmodel von Lovat! unter Berücksichtigung der Überlegungen von Kelbert? 
als generisches, systemübergreifendes, schichtenunabhängiges Tracking erwei- 
tert. Das Modell wird einer Konfiguration durch eine semantische Spezifikation 
zugänglich gemacht. 


Der Zielkonflikt zwischen Transparenz und Unverkettbarkeit erfordert die 
Entwicklung einer aussagekräftigen Metrik für Unverkettbarkeit, die dem fest- 
stehenden Zuwachs an Transparenz gegenübergestellt werden kann. Bestehende 
Ansätze für die Bestimmung des Grads der Unverkettbarkeit werden bewer- 
tet und ihre Defizite herausgearbeitet. Eine informationstheoretische Metrik 
wird anhand der datenschutzrechtlichen Anforderungen in vier Dimensionen 
instanziiert. Für jede Dimension wird die Bestimmung des Messwertes unter 
den gegebenen Annahmen hergeleitet. Ein prototypischer Simulator und ein 
implementierter Algorithmus zeigen die Berechenbarkeit der Metrik. 


Ein Datenschutzauskunftssystem ist nur so gut wie die Datenschutzauskunfts- 
plattform, die die Informationen den Betroffenen zugänglich macht. Ein Proto- 
typ für eine Datenschutzauskunftsplattform wird anhand von Überlegungen 
zur Nutzerfreundlichkeit erarbeitet und an die datenschutzrechtlichen Anfor- 
derungen angepasst. Der webbasierte Demonstrator wird gegen die neueste 
Datenschutzauskunftsplattform des Projektes A4Cloud? evaluiert. Reaktions- 
zeiten, Erfolgsquote und Nutzerverhalten werden in einem Blickmesslabor 
untersucht. Eine ergänzende Nutzerbefragung bietet ein ganzheitliches Bild 
auf die Nutzerrezeption des Datenschutzauskunftssystems. 


l Lovat 2015. 
2 Kelbert/Pretschner 2015. 
3 H. Andersson et al. 2015. 
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1.4 Wissenschaftlicher Beitrag 


Diese Arbeit befasst sich erstmalig sowohl rechtlich als auch technisch mit dem 
Recht auf Auskunft und dessen Implikationen. Sie erweitert den bisherigen 
Stand der Wissenschaft und Forschung um die folgenden neuen Beiträge: 


Eine Einordnung des Rechts auf Auskunft im Hinblick auf die automati- 
sierte Beantwortung von Auskunftsersuchen. Es wird herausgearbeitet, ob 
und inwiefern das Recht auf Auskunft im Grundgesetz (Kapitel 2.1) sowie in 
den Verträgen! (Kapitel 2.2) verankert ist. Die verfassungsrechtliche Stellung 
des Rechts auf Auskunft wurde in der Literatur bisher nicht systematisch 
erörtert. In der bis dato oberflächlichen Betrachtung ist sie strittig.” Diese 
Arbeit positioniert sich gegen ein Recht auf Auskunft und hebt die Bedeutung 
des europäischen Rechts als relativierende Größe hervor. 


Das Recht auf Auskunft wird in dieser Arbeit systematisch in den Kontext des 
Datenschutzes und die übrigen Transparenzrechte eingeordnet (Kapitel 3.1). 
Die Betrachtungen zum Umfang des Auskunftsrechts (Kapitel 3.7) machen 
deutlich, dass für eine vollständige Auskunft eine nahtlose Nachvollziehbar- 
keit der Verarbeitungswege personenbezogener Daten erforderlich ist. Eine 
solche ist letztendlich nur automatisiert zu gewährleisten. Form und Inhalt des 
Auskunftsersuchens (Kapitel 3.3), die Identifizierung des Auskunftsberech- 
tigten (Kapitel 3.4) und die Art und Weise der Auskunftserteilung (Kapitel 
3.5) werden deshalb im Hinblick auf eine automatisierte Auskunftserteilung 
analysiert.’ 


Für die Ableitung der technischen Anforderungen wird ein neues Vorgehens- 
modell vorgestellt (Kapitel 4.1.2). Es erweitert die Methode KORA,* deren 


! EUV und AEUV. 

2 Mallmann in: Simitis, BDSG 2014, $ 19 Fn. 1. 
3 Bier, DuD 2015, 741. 

4 Vgl. Kapitel 4.1.1. 
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Ableitung auf rechtlicher Ebene stehen bleibt. Anhand des Datenschutzaus- 
kunftssystems wird gezeigt, wie technische Anforderungen abgeleitet und in 
die Implementierung übertragen werden können (Kapitel 4.3). 


Das erste verteilte, datenzentrierte, integrierte und betroffenenfokussierte 
Datenschutzauskunftssystem Die bereits vorhandenen Arbeiten zu Personal- 
Data-Provenance werden in Kapitel 5.1 diskutiert. Die vorliegende Arbeit geht 
in diesem Themenbereich insbesondere in den folgenden Punkten über den 
Stand der Technik hinaus: 


Das vorgestellte Datenschutzauskunftssystem ist verteilt, da es ein schich- 
tenunabhängiges, semantisch konfigurierbares! Provenance-Tracking über 
Systemgrenzen hinweg zulässt (Kapitel 8.1) und erst zum Anfragezeitpunkt 
eine Aggregation der Personal-Data-Provenance erfordert (Kapitel 8.2). Das 
Protokollsystem Insynd speichert die Personal-Data-Provenance dagegen auf 
einem zentralen Logserver und überlässt die Aggregation dem Betroffenen.” 
Kelbert stellt zwar ein verteiltes Informationsflussmodell vor,? leitet daraus 
jedoch keine Provenance ab. Auch sind die Modelle beider Ansätze nicht durch 
eine semantische Spezifikation konfigurierbar. Eine solche Konfigurierbar- 
keit ermöglicht jedoch die Integration von datenverarbeitenden Systemen ins 
Provenance-Tracking zur Laufzeit. Dies ist in der Anwendung unabdingbar. 


Es ist datenzentriert, da das Informationsfluss- und Provenancemodell eine 
Trennung von Daten und Container vorsieht (Kapitel 6). Die Personal-Data- 
Provenance wird pro Datum statt pro Ereignis erfasst und lässt sich so individuell 
und datenminimal ablegen (Kapitel 7). Bereits das von Harvan,* Pretschner,> 
Lovat und Kelbert’ entwickelte und erweiterte Informationsflussmodell ist 
datenzentriert. Für sich alleine ist es allerdings kein Provenance-Modell. Es 


l Birnstill/Bier et al. 2016. 

2 Pulls/Peeters 2015. 

3 Kelbert/Pretschner 2015. 

4 Harvan/Pretschner 2009. 

5 Pretschner/Lovat/Büchler 2011. 
6 Lovat/Kelbert 2014. 

7 Kelbert/Pretschner 2015. 
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wird in dieser Arbeit erstmalig mit einem Provenance-Modell verknüpft und 
für den Zweck der Datenschutzauskunft verwendet. 


Das Datenschutzauskunftssystem ist integriert, da es sowohl die Bereitstellung 
der Datenschutzauskunft als auch die Durchsetzung der übrigen Betroffenen- 
rechte über Usage-Control in einer gemeinsamen Architektur (Kapitel 5) und 
einem verbundenen Modell (Kapitel 6) zulässt. Das existierende GenomSynlig 
sieht zwar einen Löschbutton vor, dessen Umsetzung ist jedoch offen. 


Die Auskunftsplattform des Datenschutzauskunftssystems ist betroffenenfokus- 
siert, da sie die interaktive und schrittweise Wahrnehmung des Auskunftsrechts 
und der Interventionsrechte zulässt (Kapitel 12).' Das Recht auf Datenübertrag- 
barkeit und die Entscheidungsfreiheit des Betroffenen sind mitberücksichtigt 
(Kapitel 10). Das einzige bereits existierende System, GenomSynlig, ermög- 
licht es dem Betroffenen nicht, die Abfolge von Datenverarbeitungsschritten 
nachzuvollziehen. 


Eine generische, instanzüerbare und berechenbare Metrik für Unverkett- 
barkeit Im Konflikt der Datenschutzziele Transparenz und Unverkettbarkeit 
ist eine Metrik für Unverkettbarkeit eine Hilfestellung für den Betroffenen.” Un- 
verkettbarkeitsmetriken wurden in der Literatur bisher aufhomogene Relationen 
oder sogar Äquivalenzrelationen beschränkt. Personenbezogene Daten können 
jedoch in Relation zu mehreren anderen Entitäten, beispielsweise der Herkunft 
und dem Empfänger, stehen. Diese Arbeit erweitert bestehende Konzepte für 
informationstheoretische Unverkettbarkeitsmetriken auf beliebige Verkettungs- 
relationen (Kapitel 9.3). Das Schema wird für vier Relationen mit Bezug zum 
entwickelten Datenschutzauskunftssystem instanziiert (Kapitel 9.7). 


Des Weiteren ist in der Literatur das Hintergrundwissen eines Angreifers in den 
Metriken bisher vollständig unberücksichtigt. Folge ist, dass die tatsächliche 
Wirkung der Einführung eines Datenschutzauskunftssystems verzerrt wird. 
In dieser Arbeit wird deshalb das A-priori- und A-posteriori-Wissen eines 


! Bier/Kühne/Beyerer 2016. 
? Bier 2016. 
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modellierten Angreifers formalisiert (Kapitel 9.8) und in die Bestimmung des 
Grads der Unverkettbarkeit miteinbezogen. 


Dariiber hinaus wurde fiir keine der in der Literatur existierenden Metriken 
die tatsächliche Berechenbarkeit belegt. Die Komplexität der vollständigen 
Berechnung der Wahrscheinlichkeiten aller möglichen Kandidatenrelationen 
liegt allerdings in O(2”). Deshalb wird in dieser Arbeit ein heuristischen 
Algorithmus zur Berechnung der Metrik hergeleitet und dessen Anwendbarkeit 
demonstriert (Kapitel 9.9). Die Metrik wird als Grundlage für eine informierte 
Entscheidung des Betroffenen bezüglich des Provenance-Trackings vorgeschla- 
gen (Kapitel 10). 


Eine vertiefte Auseinandersetzung mit verwandten Arbeiten findet sich am 
Ende dieser Arbeit in Kapitel 13.2.1. 


1.5  Vorveröffentlichungen 


Eine vollständige Liste aller Veröffentlichungen des Autors findet sich am 
Ende der Arbeit. Die hier referenzierten Veröffentlichungen sind direkt in diese 
Arbeit eingeflossen. 


Die in Abschnitt 1.1.1 erwähnte und im Anhang A ausgeführte Studie zum 
Status Quo des Auskunftsanspruchs wurde gemeinsam mit Kömpf durchgeführt 
und veröffentlicht. ! Eine Zusammenfassung des Kapitels 3 wurde bereits 2015 
publiziert.” Die im Kapitel 5 vorgestellte Integration von Usage-Control- und 
Provenance-Architektur wurde bereits 2013 vorgeschlagen.’ 


Die Modelle und Verfahren der Kapitel 6.2.1 und 8.1.1 sind in Zusammenarbeit 
mit Birnstill entstanden.* Gegenüber dem veröffentlichten Stand von 2016 


! Bier/Kömpf/Beyerer 2017. 
2 Bier, DuD 2015, 741. 

3 Bier 2013b. 

4 Birnstill/Bier et al. 2016. 
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wurden die Modelle in dieser Arbeit um abstrakte Container erweitert. Die 
Verfahrensbeschreibung in Kapitel 8.1.2 berücksichtigt zusätzlich den Aufbau 
der Provenance. 


Das Kapitel 9 zur Unverkettbarkeit basiert auf den auf der Jahrestagung 
Informatik 2016 vorgestellten Arbeiten.! Die Nutzerstudie des Kapitels 12 
wurde gemeinsam mit Kühne durchgeführt und veröffentlicht.” 


1.6 Fortlaufendes Beispiel 


Die in dieser Arbeit vorgestellten Konzepte werden anhand eines durchgängigen 
Szenarios erläutert. Das Szenario ist typisch für Auskunftsersuchen und deckt 
die wesentlichen rechtlichen und technischen Aspekte ab, die in dieser Arbeit 
eingeführt werden. 


Das fortlaufende Beispiel nimmt ein Unternehmen namens AdBokis Buch- 
club GmbH, einen fiktiven Online-Händler für Bücher und Software, in den 
Fokus. Alice Fox ist Kundin dieses Händlers. Sie hat im Onlineshop eine 
Banking-Software gekauft und sich dafür ein Benutzerkonto angelegt. Mit der 
Bestellbestätigung erhält Alice eine Einladung zu einem Incentive-Programm. 
Im Austausch gegen einen Rabatt willigt Alice darin ein, in Zukunft über 
interessante Produkte von AdBokis und Partnern informiert zu werden. Im 
weiteren Verlauf hat Alice eine Frage an den Support von AdBokis. In diesem 
Rahmen übermittelt sie weitere personenbezogene Daten. 


Etwas später erhält Alice per E-Mail einen Newsletter von einer Bonus Card 
GmbH. Sie möchte jetzt wissen, wie ihre Daten an das Unternehmen gekommen 
sind. Da sie von der Bonus Card GmbH keine Antwort erhält erkundigt sie sich 
bei AdBokis. Nur dort hatte sie die für den Newsletter genutzte E-Mailadresse 
zur Registrierung verwendet. 


! Bier 2016. 
? Bier/Kühne/Beyerer 2016. 
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1.7 Imhaltsübersicht 


Kapitel 1: Einleitung 


Im vorangegangenen ersten Kapitel wurde der Handlungsbedarf fiir die Ent- 
wicklung eines integrierten Datenschutzauskunftssystems herausgearbeitet. 
Insbesondere wurde eine eigens erstellte Studie zum Status quo des Rechts 
auf Auskunft vorgestellt. AnschlieBend wurde die Zielsetzung der Arbeit mit 
den zugrundeliegenden Forschungsfragen und Forschungshypothesen erläutert. 
Anknüpfend wurden die in der Arbeit verwendeten Lösungsstrategien zur 
Erarbeitung der wissenschaftlichen Beiträge dargelegt. Zuletzt wurde das in 
dieser Arbeit verwendete fortlaufende Beispiel eingeführt. 


Teil I: Rechtliche Grundlagen und Anforderungen 


Kapitel 2: Verfassungs- und europarechtliche Grundlagen 


Im zweiten Kapitel wird die Verankerung des Rechts auf Auskunft im 
Grundgesetz und in den Verträgen herausgearbeitet. Die dem Recht auf 
Auskunft entgegenstehenden Grundrechte und die aktuelle Rechtsentwicklung 
in Europa werden mitberücksichtigt. 


Kapitel 3: Einfachgesetzliche Verankerung des Rechts auf Auskunft 


Das Kapitel 3 spannt den Bogen von der Struktur des Datenschutzes über 
Form, Art und Inhalt eines Auskunftsbegehrens bis zum Umfang der Auskunft 
selbst. Dabei wird ein besonderer Schwerpunkt auf die bei der Automatisierung 
der Auskunft zu berücksichtigenden Aspekte gelegt. 
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Kapitel 4: Datenschutzrechtliche Anforderungen an ein Datenschutzaus- 
kunftssystem 


Im Kapitel 4 wird ein Vorgehensmodell zur Ableitung technischer Anforderun- 
gen, ausgehend von den Grundrechten, vorgestellt. Dieses Vorgehensmodell 
wird anschlieBend auf die Anforderungen an ein Datenschutzauskunftssystem 
angewendet. 


Teil II: Personal-Data-Provenance und Data-Usage-Control 


Kapitel 5: Usage-Control & Provenance-Tracking: Einführung und Ar- 
chitektur 


Im Kapitel 5 werden die Konzepte von Usage-Control & Provenance-Tracking 
eingeführt und diskutiert. Ausgehend von existierenden Forschungsansätzen 
wird entlang der rechtlichen Anforderungen eine integrierte, generische 
Architektur erarbeitet. 


Kapitel 6: Ein gemeinsames Modell für IF- & Provenance-Tracking 


Aufbauend auf dem vorherigen Kapitel wird im Kapitel 6 ausgehend von 
bestehenden Informationsfluss- und Provenancemodellen ein gemeinsames 
Informationsfluss- und Provenancemodell entwickelt. Aspekte der Implemen- 
tierung, insbesondere der Personal-Data-Provenance-Datenhaltung werden 
angerissen. 


Kapitel 7: Datenschutzgerechtes und skalierbares Provenance-Tracking 


Im Kapitel 7 wird der Mechanismus zur Erhebung und Speicherung 
von Personal-Data-Provenance verfeinert, um zu einer datenminimalen 
und skalierbaren Umsetzung zu kommen. Ein wesentlicher Aspekt sind 
Abstraktionsregeln. Die vorgestellten Konzepte werden im Rahmen von 
Performance-Tests evaluiert. 
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Kapitel 8: Verteiltes Provenance-Tracking 


Provenance-Tracking ist nicht auf ein lokales System beschränkt, sondern muss 
systemübergreifend erfolgen. Im Kapitel 8 wird ein Konzept für ein schichtun- 
abhängiges, semantisch konfigurierbares, systemübergreifendes Provenance- 
Tracking vorgestellt. Ergänzend wird die Datenaggregation zum Auskunftszeit- 
punkt behandelt. 


Teil III: Abwägung zwischen Transparenz und 
Unverkettbarkeit 


Kapitel 9: Eine Metrik für Unverkettbarkeit 


Im Kapitel 9 wird auf den Zielkonflikt zwischen Transparenz und Unver- 
kettbarkeit eingegangen. Es wird eine informationstheoretische Metrik für 
Unverkettbarkeit definiert und instanziiert. Ein Verfahren zur Berechung der 
Metrik wird vorgestellt. 


Kapitel 10: Betroffenenautonomie zwischen Transparenz und Unverkett- 
barkeit 


Die Unverkettbarkeitsmetrik gibt dem Betroffenen ein Hilfsmittel in die Hand, 
um selbst abzuwägen, welches Datenschutz-Schutzziel ihm wichtiger ist. Im Ka- 
pitel 10 wird die Einbindung dieser Wahlmöglichkeit in die Auskunftsplattform 
diskutiert und evaluiert. Konsequenzen für das Recht auf Datenübertragbarkeit 
werden hervorgehoben. 
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Teil IV: Bewertung und Ausblick 


Kapitel 11: Rechtliche Bewertung des Datenschutzauskunftssystems 


Im Kapitel 11 wird das Datenschutzauskunftssystem einer abschließenden 
rechtlichen Bewertung auf der Grundlage der in Kapitel 2 bis 4 hergeleiteten 
Anforderungen unterzogen. Die Konsequenzen einer fehlerhaften Auskunft 
werden diskutiert. 


Kapitel 12: Nutzerrezeption des Datenschutzauskunftssystems 


Das Kapitel 12 stellt eine Nutzerstudie vor, in der die Angemessenheit und 
Nutzerfreundlichkeit der Auskunftsplattform überprüft wurde. Dazu werden 
konkurrierende Ansätze eingeführt und mit dem eigenen Auskunftssystem 
verglichen. 


Kapitel 13: Zusammenfassung und Ausblick 


Im letzten Kapitel werden die Ergebnisse dieser Arbeit zusammengefasst 
und bewertet. Die Grenzen der Arbeit werden benannt. Zuallerletzt wird ein 
Ausblick auf zukünftige rechtliche und technische Entwicklungen gegeben. 
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Rechtliche Grundlagen und 
Anforderungen 
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2 Verfassungs- und europarechtliche 
Grundlagen 


Das Verfassungs- und europarechtliche Gefiige aus GG, EMRK, Charta und 
Verträgen bildet den Rahmen für die Interpretation und Auslegung einfachen 
Rechts. Insbesondere in Abwägungsgrenzfällen ist es wichtig, miteinzubezie- 
hen, welche Rechtspositionen sich auf welche Grundrechte berufen können. 


Der Grundrechtscharakter des Rechts auf Auskunft ist in der Literatur bisher 
strittig.! Deshalb wird in diesem Kapitel schwerpunktmäßig behandelt, ob 
das Recht auf Auskunft teil des Grundrechts auf informationelle Selbstbe- 
stimmung (Abschnitt 2.1) und der europäischen Grundrechte (Abschnitt 2.2) 
ist. Detaillierte europarechtliche Vorgaben, wie sie sich in der DSRL und der 
künftig geltenden DSGVO finden, werden nicht in diesem Kapitel, sondern im 
jeweiligen Kontext in den Kapiteln 3 und 10 behandelt. 


l Mallmann in: Simitis, BDSG 2014, § 19 Fn. 1; fiir ein Auskunftsrecht als Bestandteil des Rechts 
auf informationelle Selbstbestimmung Di Fabio in: Maunz/Diiring, GG 2016, Art. 2 Abs. 1 Rn. 
178; Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 49; Gola/Schomerus, BDSG 2015, § 19 
Rn. 2; Dix in: Simitis, BDSG 2014, § 34 Rn. 2; Weichert, NVwZ 2007, 1004 (1005). 
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2 Verfassungs- und europarechtliche Grundlagen 


2.1 Verfassungsrechtliche Rahmensituation 


2.1.1 Das Grundrecht auf informationelle 
Selbstbestimmung 


Schutzgegenstand des Datenschutzrechts ist das allgemeine Persönlichkeits- 
recht! des Einzelnen in seiner Ausprägung als Recht auf informationelle 
Selbstbestimmung aus Art. 2 I i. V.m. Art. 1 I GG.? 


Das Recht auf informationelle Selbstbestimmung steht allen lebenden na- 
türlichen Personen unabhängig von ihrer Staatsangehörigkeit zu, soweit sie 
unmittelbar betroffen sind.” Es ist Teil der Informations- und Kommunikations- 
verfassung des Grundgesetzes* und Auffanggrundrecht neben den spezielleren 
Freiheitsrechten der Art. 10, 13 GG.° Es steht neben anderen Schutzrechten 
wie dem Schutz der Privatsphäre, dem Recht am eigenen Bild und dem Recht 
am eigenen Wort. In seinem Bezug auf die Menschenwürde’ geht es über den 
Schutzbereich des Art. 2 Abs. 1 GG hinaus.® 


In seiner subjektiven Ausprägung gewährleistet das Grundrecht „die Befug- 
nis des Einzelnen, grundsätzlich selbst über die Preisgabe und Verwendung 
seiner persönlichen Daten zu bestimmen.‘“? Objektivrechtlich schützt es die 
freiheitlich demokratische Kommunikationsverfassung. Eine Gesellschafts- 
ordnung, „in der Bürger nicht mehr wissen können, wer was wann und bei 


1 BVerfGE 54, 148 (153). 

2 BVerfGE 65, 1 (41). 

3 Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 36. 

4 Gallwas, NJW 1992, 2785 (2785). 

5 BVerfGE 67, 157 (171); BVerfGE 100, 313 (358); BVerfGE 118, 168 (183). Umstände der 
Telekommunikation, beispielsweise Verkehrs- und Verbindungsdaten, befinden sich im Schutzbe- 
reich des Art. 10 GG, soweit sie nicht im Herrschaftsbereich eines Kommunikationsteilnehmers 
gespeichert sind. — BVerfGE 115, 166 (166); BVerfGE 124, 43 (54). 

6 BVerfGE 34, 238 (246). 

7 BVerfGE 30, 1 (25 f.). 

8 BVerfGE 35, 202 (220); BVerfGE 109, 279 (313). 

9 BVerfGE 65, 1 (43). 
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welcher Gelegenheit über sie weiß“ ist mit dem Recht auf informationel- 
le Selbstbestimmung unvereinbar. ! Biirger, die dauerhaft versuchen, nicht 
durch abweichende Verhaltensweisen aufzufallen, können einen demokrati- 
schen pluralistischen Rechtsstaat wie die Bundesrepublik Deutschland nicht 
stützen. „Selbstbestimmung [ist] eine elementare Funktionsbedingung eines 
auf Handlungsfähigkeit und Mitwirkungsfähigkeit seiner Bürger begründeten 
freiheitlich-demokratischen Gemeinwesens.“? 


Der Einzelne hat jedoch kein absolutes, eigentumsähnliches Herrschaftsrecht 
über seine personenbezogenen Daten. Das Grundgesetz folgt einem Men- 
schenbild, das den Menschen nicht allein als isoliertes Individuum betrachtet, 
sondern ihn in seiner ganzen Gemeinschaftsbezogenheit als soziales Wesen 
erfasst.” Kommunikationsbeziehungen, veröffentlichte und ausgetauschte In- 
formationen sind ein Abbild der sozialen Realität und bilden mannigfache 
Bezüge.* 


2.1.2 Drittwirkung der Grundrechte 


Die Grundrechte binden den Staat unmittelbar. Sie sind ,,Abwehrrechte des 
Bürgers gegen den Staat“. Aufgrund der „Asymmetrie des Rechtsstaats“® gilt 
diese Bindung für den Bürger oder privatwirtschaftliche Unternehmen nicht. 
Art. 1 Abs. 3 GG trifft dazu eine elementare Unterscheidung.” „Private stehen 
sich in Freiheit gegenüber.“ ® 


Dennoch ist das Recht auf informationelle Selbstbestimmung Teil der Wertord- 
nung des Grundgesetzes und damit objektives Prinzip für die Gestaltung des 


' Ebd. 

2 Ebd. 

3 BVerfGE 4, 7 (15 f.); BVerfGE 35, 202 (220). 
4 BVerfGE 65, 1 (43 f.). 

5 BVerfGE 7, 198 (204). 

6 Masing, NJW 2012, 2305 (2306). 

1 BVerfGE 128, 226 (244). 

8 Masing, NJW 2012, 2305 (2307). 
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Privatrechts.! Daraus ergeben sich Schutzpflichten für die staatlichen Organe 
gegenüber dem Bürger in seinem Verhältnis zu privaten Dritten.” Das Recht 
auf informationelle Selbstbestimmung entfaltet damit mittelbar auch seine 
Wirkung für das Verhältnis Privater untereinander.’ 


Dies bedeutet jedoch nicht, dass für das Verhältnis Privater die selben Stan- 
dards gelten wie im öffentlichen Bereich.* Kollidierende Grundrechte sind in 
ihrer Wechselwirkung so zu begrenzen, dass sie in praktischer Konkordanz 
nebeneinander bestehen können.” Allerdings können je nach Intensität des 
Machtungleichgewichts die an den Gesetzgeber gestellten Anforderungen für 
die Regelung einer Datenverarbeitung durch Private genauso streng sein wie 
die Anforderungen, die durch die Grundrechte an staatliche Akteure gerichtet 
sind.6 


2.1.3 Verankerung des Rechts auf Auskunft im 
Grundgesetz 


Ein Recht auf Auskunft kann sich nicht auf auf die Informationsfreiheit nach 
Art. 5 Abs. 1 S. 1, 2. Hs. GG beziehen, sondern nur aus dem Recht auf 
informationelle Selbstbestimmung speisen. 


Ob das Auskunftsrecht Bestandteil des Rechts auf informationelle Selbstbe- 
stimmung ist, ist in der Literatur strittig.’ 


' BVerfGE 7, 198 (198); BVerfGE 81, 242 (254). 

2 BVerfGE 117, 202 (227 ff. 

3 BVerfGE 7, 198 (205); BVerfGE 84, 192 (194 £.). 

4 Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 29. 

5 BVerfGE 89, 214 (232). 

6 BVerfGE 81, 242 (255); Masing, NJW 2012, 2305 (2308). 

7 Mallmann in: Simitis, BDSG 2014, § 19 Fn. 1; fiir ein Auskunftsrecht als Bestandteil des Rechts 
auf informationelle Selbstbestimmung Di Fabio in: Maunz/Diiring, GG 2016, Art. 2 Abs. 1 Rn. 
178; Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 49; Gola/Schomerus, BDSG 2015, § 19 
Rn. 2; Dix in: Simitis, BDSG 2014, § 34 Rn. 2; Weichert, NVwZ 2007, 1004 (1005). 
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Das Bundesverfassungsgericht (BVerfG) hat die Frage nach einem Leistungs- 
recht auf Auskunft selbst lange, insbesondere im Bezug auf das Volkszäh- 
lungsurteil, explizit offen gelassen. Die dortigen Nennungen von Auskunfts-, 
Aufklärungs- und Löschpflichten! stehen exemplarisch für mögliche verfah- 
rensrechtliche Sicherungen.” 


Unstrittig war schon immer, dass ein fehlender Zugang zu gespeicherten 
personenbezogenen Daten das Verhältnismäßigkeitsprinzip als Teil des Rechts 
auf informationelle Selbstbestimmung berühren kann, unabhängig davon, ob es 
ein eigenes Zugangsrecht gibt oder nicht.” Verfahrensgarantien wird ein hoher 
Stellenwert eingeräumt.* 


Darüber hinaus ist der Anspruch auf Kenntnis ein in sich eigenes und spezifi- 
sches Datenschutzrecht.° 


Erst 2008 hat das Bundesverfassungsgericht klargestellt, dass das Grundgesetz 
dem Gesetzgeber nicht vorgibt, wie die Möglichkeit der Kenntnisnahme auszu- 
gestalten ist. „Das Grundrecht auf informationelle Selbstbestimmung gewährt 
[..] keinen Anspruch auf eine bestimmte Art der Informationserlangung.“® 


Die Prüfung der Verhältnismäßigkeit eines Eingriffs kommt bei heimlichen 
Datenerhebungen eher zu dem Ergebnis, dass eine Benachrichtigung geboten 
ist.” Besteht eine solche Verpflichtung nicht und sind Eingriffe nicht klar 
abzuschätzen, kommt dem, durch den Betroffenen initiativ wahrzunehmenden, 


1 BVerfGE 65, 1 (46); BVerfGE 113, 29 (58). 

2 BVerfG, NVwZ 2001, 185 (185); BVerfG, NJW 2006, 1116 (1117) und dem folgend BVerwGE 
130, 29 (36). 

3 BVerfG, NJW 2006, 1116 (1117). 

4 BVerfGE 113, 29 (57 f.). 

5 BVerfGE 100, 313 (361). 

6 BVerfGE 120, 351 (363); bereits zu Art. 10 GG in BVerfGE 100, 313 (361) und zu Art. 13 GG 
in BVerfGE 109, 279 (363); abweichende Interpretation Gola/Schomerus, BDSG 2015, § 19 Rn. 
2, die das Recht auf Kenntnisnahme mit dem Recht auf Auskunft gleichsetzen. 

7 BVerfGE 120, 351 (363). 
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Auskunftsrecht eine zentrale Bedeutung zu.! Umgekehrt ist eine Benachrich- 
tigung immer dann erforderlich, wenn Daten heimlich erhoben werden und 
Auskunftsansprüche nicht eingeräumt werden.” 


Ein wirksamer Anspruch muss sich auf alle Erhebungs- und Verarbeitungs- 
prozesse und jede Nutzung erstrecken.* Eine reine Benachrichtigung zum 
Erhebungszeitpunkt ist deshalb verfassungsrechtlich nicht ausreichend. Wird 
auf ein Auskunftsrecht verzichtet, ist der Betroffene wiederholt zu benachrich- 
tigen. 


In summa kann festgestellt werden, dass es kein verfassungsrechtlich veran- 
kertes Recht auf Auskunft gibt. Verfassungsrechtlich geschiitzt ist dagegen die 
Kenntnisnahme in einer offenen Ausprägung. 


Der Gesetzgeber hat jedoch u.a. im $ 19 Abs. 1 und $ 34 Abs. 1 BDSG 
entschieden, Transparenz durch einen Auskunftsanspruch herzustellen. Der 
Gesetzgeber überträgt durch seine Rechtsetzung die an ihn verfassungsmäßig 
gestellten Anforderungen auf das Verhältnis zwischen Privaten bzw. Bürgern. 
Die Prüfung und Interessenabwägung der verantwortlichen Stelle ist dem- 
entsprechend entlang ähnlicher Maßstäbe durchzuführen, wie sie auch für die 
exekutive Gewalt gelten. 


Der Auskunftsanspruch ist „Ausdruck demokratischer und rechtsstaatlicher 
Grundvorstellungen.“ Er „wirkt der Gefahr entgegen, dass sich der Bürger 
unkontrollierbarem Wissen und damit unkontrollierbarer Macht ausgeliefert 
sieht und deshalb [...] auf die Ausübung von Grundrechten verzichtet.“* 


Im Verhältnis zwischen den Bürgern soll durch das Datenschutzrecht gleichfalls 
ein Machtungleichgewicht reduziert werden. Aus diesem Grunde gilt das 
BDSG nicht für die Erhebung, Verarbeitung und Nutzung personenbezogener 
Daten im privaten, höchstpersönlichen Bereich. Für diesen Bereich sind der 


1 BVerfGE 120, 351 (364); BVerfG, Urteil des Ersten Senats vom 20. April 2016 - 1 BvR 966/09 
Rn. 137, http://www.bverfg.de/e/rs20160420_1bvr096609.html, abgerufen am 9. Mai 2017. 

2 BVerfGE 109, 279 (363 f.). 

3 BVerfGE 100, 313 (361). 

4 Mallmann in: Simitis, BDSG 2014, $ 19 Rn. 3. 
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Unterlassungsanspruch, das Kunsturhebergesetz und strafrechtliche Sanktionen 
im Rahmen der üblen Nachrede relevant. 


Das Auskunftsrecht trägt der Gewährung effektiven Rechtsschutzes aus Art. 19 
Abs. 4 GG Rechnung.! Es schafft die Voraussetzung dafiir, dass der Betroffene 
Kenntnis von unrechtmäßiger Datenerhebung und -verwendung erlangen kann, 
und ist damit die Grundlage für die Beschwerde bei der Aufsichtsbehörde 
und die Anrufung der zuständigen Gerichte. Die Möglichkeit, von Eingriffen 
in das Recht auf informationelle Selbstbestimmung zu erfahren, bietet Ori- 
entierung und Erwartungssicherheit. Der Anspruch ist jedoch nicht auf den 
gerichtlichen Rechtsschutz nach Art. 19 Abs. 4 GG verengt.” Informations- 
möglichkeiten für den Betroffenen sind Voraussetzung dafür, dass er seine 
übrigen Betroffenenrechte geltend machen kann.’ 


Das durch Art. 2 Abs. 1 i. V.m. Art. 1 Abs. 1 GG gewährleistete allgemeine 
Persönlichkeitsrecht schützt den selbst definierten sozialen Geltungsanspruch 
eines jeden einzelnen. Es berechtigt zur Korrektur von Äußerungen, die 
dem einzelnen unrechtmäßig in den Mund gelegt werden.* Damit ist das 
allgemeine Persönlichkeitsrecht auch ein möglicher Ausgangspunkt für den 
datenschutzrechtlichen Löschanspruch. 


Adäquate technische und organisatorische Vorkehrungen, um im Fall einer 
Betroffenenanfrage Auskunft geben zu können, sind Erfordernisse eines ef- 
fektiven Grundrechtsschutzes.° Daraus lässt sich ein verfassungsrechtlicher 
Auftrag herleiten, wirksame technische Systeme zur Auskunftserteilung zu 
entwickeln. 


1 BVerfGE 65, 1 (70); BVerfGE 120, 351 (362). 
2 BVerfGE 100, 313 (361). 

3 BVerfGE 120, 351 (362 £.). 

4 BVerfG, NIW 1980, 2070. 

5 BVerfGE 35, 79 (120); BVerfGE 56, 216 (238). 
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2.1.4 Schranken 


Beschränkungen des Rechts auf Kenntnisnahme müssen gegenläufigen In- 
teressen dienen, die von größerem Gewicht sind als das Recht selbst.! Sie 
unterliegen den gleichen Voraussetzungen wie Beschränkungen des Rechts auf 
informationelle Selbstbestimmung. ? 


2.1.5 Entgegenstehende Grundrechte anderer Personen 
In Frage kommende Grundrechte 


Das Sammeln und die Verwendung personenbezogener Daten ist für Private 
(nicht-6ffentliche Stellen) durch Art. 2 Abs. 1 GG (Allgemeine Handlungs- 
freiheit), Art. 5 Abs. 1 S. 1, 2. Hs. (Informationsfreiheit), aber auch durch 
Art. 4 (Religions- und Gewissensfreiheit), Art. 12 (Berufsfreiheit) und Art. 14 
(Eigentumsfreiheit) geschützt.” Natürliche Personen haben als Teil des Rechts 
auf informationelle Selbstbestimmung ein Recht zur Verwendung von Daten 
mit mehrfachem Personenbezug. Juristische Personen können sich nicht auf 
das Recht auf informationelle Selbstbestimmung berufen.* Aus dem Recht 
auf Verwendung ergibt sich jedoch noch kein Recht auf Zugang zu fremden 
personenbezogenen Daten (Erhebung).° Ein Recht auf Übermittlung wird er- 
gänzend durch die Meinungsfreiheit gestützt. Sie hat einschränkenden Charakter 
gegenüber dem Recht auf informationelle Selbstbestimmung.® 


In den genannten Grundrechtspositionen Dritter beziehungsweise der verant- 
wortlichen Stelle, soweit sie grundrechtsberechtigt sind, findet das Recht auf 
Kenntnisnahme seine Grenzen.’ 


! BVerfGE 120, 351 (365); BVerfGE 133, 277 (368). 

2 OVG Bremen, NJW 1987, 2393 (2394); analog zu Art. 13 GG: BVerfGE 109, 279 (364). 
3 Gallwas, NJW 1992, 2785 (2787); Masing, NJW 2012, 2305 (2307). 

4 Gurlit, NTW 2010, 1035 (1036). 

5 Gallwas, NJW 1992, 2785 (2788). 

6 Gallwas, NJW 1992, 2785 (2789). 

7 BVerfG, NIW 1999, 1777 (1777). 
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Dem allgemeinen Persönlichkeitsrecht entspringt ein personenbezogenes Ab- 
wägungsgebot zwischen Abwehrinteresse und Beeinträchtigungsinteresse.! 
Durch die Abwägung kann es in jedem Schritt wieder zu neuen Abwehrrechten 
und Ansprüchen des Grundrechtsberechtigten gegenüber dem Grundrechtsver- 
pflichteten kommen.” Der Anspruch auf Auskunft ist solch ein nachgelagerter 
Gegenstand. 


Die einfachgesetzlichen Regelungen zur Datenverarbeitung Privater 
(z.B. $ 28 ff. BDSG) haben zum Ziel, die mehrseitigen Freiheitsrechte in 
Ausgleich zu bringen. 


Betriebs- und Geschäftsgeheimnisse 


Die Erteilung einer Datenschutzauskunft durch Unternehmen berührt insbeson- 
dere deren geschäftliche Interessen. Der Schutz von Betriebs- und Geschäfts- 
geheimnissen hat einen ähnlichen Stellenwert für eine freie, selbstbestimmte 
Gesellschaft, wie der Schutz von personenbezogenen Daten.” Eine Abwägung 
zwischen diesen Schutzgütern ist deshalb geboten. Gemäß der Rechtsprechung 
des Bundesverwaltungsgerichts (BVerwG) sind Betriebs- und Geschäftsge- 
heimnisse gemeinsam durch Art. 12 und Art. 14 GG geschützt.* Das Grundrecht 
auf Berufsfreiheit ist auf juristische Personen? sowie auf Handelsgesellschaf- 
ten, die keine juristischen Personen sind, aber für eine Personenmehrheit 
natürlicher Personen auftreten, anwendbar.® Aus Sicht der Eigentumsfreiheit 
bilden Betriebs- und Geschäftsgeheimnisse einen eigenen Vermögenswert.’ 
Das BVerfG hat bisher offen gelassen, ob Betriebs- und Geschäftsgeheimnisse 
von der Eigentumsgarantie geschützt sind oder nur durch die Berufsfreiheit.® 


! Gallwas, NJW 1992, 2785 (2785). 

? Gallwas, NJW 1992, 2785 (2786). 

3 Spiecker genannt Döhmann 2009, 30. 
4 BVerwG, NVwZ 2009, 1114 (1116). 
5 BVerfGE 50, 290 (363). 

6 BVerfGE 10, 89 (99). 

7 Kloepfer/Greve 2011, 579. 

8 BVerfGE 115, 205 (229). 
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Jedenfalls wiirde ein Schutz durch Art. 14 GG nicht weiter gehen als der durch 
Art. 12 GG.! 


„Als Betriebs- und Geschäftsgeheimnisse werden alle auf ein Unternehmen 
bezogene Tatsachen, Umstände und Vorgänge verstanden, die nicht offenkun- 
dig, sondern nur einem begrenzten Personenkreis zugänglich sind und an deren 
Nichtverbreitung der Rechtsträger ein berechtigtes Interesse hat. Betriebsge- 
heimnisse umfassen im Wesentlichen technisches Wissen im weitesten Sinne; 


Geschäftsgeheimnisse betreffen vornehmlich kaufmännisches Wissen.“ ? 


Eine Veröffentlichung von Betriebs- und Geschäftsgeheimnissen wäre eine Ein- 
schränkung der erfolgreichen Berufsausübung, da mögliche Marktvorsprünge 
im Wettbewerb nivelliert wiirden.* 


Damit eine Information vom Schutzbereich des Betriebs- und Geschäftsge- 
heimnisses erfasst wird, müssen vier Voraussetzungen erfüllt sein:* Erstens 
muss die Information einen Unternehmensbezug besitzen. Rein private oder 
wissenschaftliche Informationen sind ausgeschlossen. Zweitens muss die 
Nichtoffenkundigkeit der Information gegeben sein. Ist die Information unter 
Zuhilfenahme erlaubter Mittel für Dritte zugänglich, ist sie nicht schützenswert. 
Drittens muss das Unternehmen seinen Geheimhaltungswillen erklärt oder 
konkludent erkennbar gemacht haben. Zuletzt muss ein berechtigtes Interesse 
an der Geheimhaltung der Information vorhanden sein. Das Interesse muss 
wirtschaftlicher Natur sein. Seine Berechtigung ist abhängig von der Stellung 
des Unternehmens im Wettbewerb. Für einen Monopolisten ist es schwie- 
riger zu argumentieren, dass eine Veröffentlichung unternehmensbezogener 
Informationen seine Marktstellung gefährdet. 


1 BVerfGE 115, 205 (248). 

2 BVerfGE 115, 205 (230 f.). 

3 Kloepfer/Greve 2011, 578. 

4 Kloepfer/Greve 2011, 580 ff.; Spiecker genannt Döhmann 2009, 32. 
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2.2 FEuroparechtliches Fundament 


Das Datenschutzrecht ist seit der DSRL von 1995 stark durch das Europarecht 
geprägt. Der Einfluss des Europarechts wird durch die DSGVO in den nächsten 
Jahren noch steigen. 


Die Europäisierung des Datenschutzrechts bewegt sich in einem komplexen 
Rechtsschutzgebilde aus EMRK, Unionsrecht und nationalem Verfassungsrecht. 
Daher ist zunächst zu klären, wie die unterschiedlichen rechtlichen Ordnungen 
zueinander in Beziehung stehen. Darauf aufbauend ist zu ergründen, inwiefern 
das Europarecht ein Recht auf Auskunft vorsieht und ob sich die Ausgestaltung 
des Rechts auf Auskunft durch die DSGVO wesentlich ändert. 


2.2.1 Verhältnis der rechtlichen Ordnungen 


Das Verhältnis der europäischen und nationalen Rechtsordnungen ist äußerst 
komplex und vielfältig. Es kann an dieser Stelle nur angerissen, aber nicht 
abschließend beleuchtet werden. Entscheidend sind die Auswirkungen auf das 
Datenschutzrecht, insbesondere die Transparenzrechte. 


EMRK und nationales Recht Die im Rahmen des Europarates entstandene 
EMRK gilt in der Bundesrepublik Deutschland im Range des Zustimmungsge- 
setzes nach Art. 59 Abs. 2 S. 1 Alt. 2 GG, eines einfachen Bundesgesetzes. ! 
Damit könnte die EMRK nach dem Grundsatz „lex posterior derogat legi 
priori“ durch neuere Bundesgesetzgebung verdrängt werden.” 


Allerdings sind nach der Rechtsprechung des BVerfG der Inhalt und der 
Entwicklungsstand der EMRK bei der Auslegung der korrespondierenden 
Grundrechte in Betracht zu ziehen.” Die Rechtsprechung des Europäischen 
Gerichtshofs für Menschenrechte (EGMR) dient als Auslegungshilfe, erlangt 


' BGBI. 1954 TI S. 14. 
? Herdegen 2016, $ 3 Rn. 53. 
3 BVerfGE 75, 358 (370); BVerfGE 111, 307 (317). 
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jedoch keine unmittelbare Bindungswirkung fiir die nationalen Gerichte. 
Gerichte miissen sich nichtsdestotrotz mit Entscheidungen des EGMR, die 
fiir den konkreten Einzelfall getroffen wurden, erkennbar und nachvollzieh- 
bar auseinandersetzen.! Wegen des völkerrechtsfreundlichen Charakters des 
Grundgesetzes sind Konventionsverstöße, auch über den konkreten Einzelfall 
hinaus, zu vermeiden.? 


Art. 8 Abs. 1 EMRK schützt in allgemeiner Form die elektronische Kommu- 
nikation? und die Verarbeitung personenbezogener Daten.* Der verwendete 
Begriff der ,,Privatheit ist entsprechend weit.’ 


Ergänzt wird die EMRK durch das Übereinkommen 108 des Europarates zum 
Schutz des Menschen bei der automatischen Verarbeitung personenbezogener 
Daten vom 28.1.1981. In diesem Übereinkommen wird im Art. 8 Lit. a und b 
ein Recht auf Kenntnisnahme statuiert. Das Übereinkommen 108 wurde von 
allen Mitgliedsstaaten der Europäische Union unterzeichnet und ratifiziert.® 


Unionsrecht und Grundgesetz Das Unionsrecht ist in den Mitgliedsstaaten 
unmittelbar wirksam.” Das nationale Recht ist primär- und sekundärrechtskon- 
form auszulegen. Die Mitgliedsstaaten sind verpflichtet ihre Rechtsordnung 
dem Unionsrecht anzupassen. Dies gilt nach Inkrafttreten der DSGVO insbe- 
sondere für das BDSG. 


Die allgemeinen Rechtsgrundsätze der Mitgliedsstaaten und die Charta der 
Grundrechte der Europäischen Union stehen nach Art. 6 Abs. 1 EUV auf 


1 BVerfGE 111, 307 (324). 

2 BVerfGE 128, 326 (368 f.). 

3 EGMR, MMR 2007, 431 (432). 

4 EGMR, NJW 2011, 1333 (1334 f.). 

5 EGMR, NJW 2014, 1645 (1646). 

6 http://www.coe.int/de/web/conventions/full-list/-/conventions/treaty/108/signatures, abgerufen 
am 9. Mai 2017. 

1 Ehlers in: Schulze/Zuleeg/Kadelbach 2015, § 11 Rn. 9. 

8 Zuleeg/Kadelbach in: Schulze/Zuleeg/Kadelbach 2015, § 8 Rn. 6. 
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der Ebene des primären Unionsrechts.! Sie sind den Verträgen rechtlich 
gleichrangig. 


Das Unionsrecht enthält Grundfreiheiten und Grundrechte. Während die Grund- 
freiheiten nur bei grenzüberschreitendem Bezug ihre Wirksamkeit entfalten, 
gelten die Grundrechte auch bei Inlandssachverhalten.* Die Adressaten der 
Charta sind nach Art. 51 GRCh die Union selbst, ihre Organe, Einrichtungen 
und Stellen sowie die Mitgliedsstaaten bei der Durchführung von Unionsrecht. 
Bezüglich des Anwendungsbereichs der Charta ist noch ungeklärt, ob der 
notwendige Unionsbezug restriktiv oder weit auszulegen ist.” 


Der Europäische Gerichtshof (EuGH) geht von einem strikten Vorrang des 
Unionsrechts gegenüber nationalem Recht aus.* Er begründet dies unter 
anderem mit der Stellung des Unionsrechts als eigene autonome Rechtsordnung 
und mit der Sicherung der Funktionsfähigkeit der Union.” Innerhalb der Charta 
statuiert Art. 53 GRCh, dass die Charta keinen geringeren Grundrechtsschutz 
bietet als die Verfassungen der Mitgliedsstaaten. Nach Auffassung des EuGH 
ist Art. 53 eng auszulegen.® Er bedeutet keine Einschränkung des Vorrangs des 
Unionsrechts. 


Beim Vorrang des Unionsrechts handelt sich um einen Anwendungsvorrang, 
nicht um einen Geltungsvorrang.’ Deutsche Regelungen zum Datenschutz 
gelten deshalb auch nach Inkrafttreten der DSGVO unverändert weiter, $ 
dürfen jedoch dort nicht angewendet werden, wo Konflikte auftreten.” Dies 
schließt indirekte Kollisionen mit ein.!" Ergänzende Regelungen bleiben 


! Ebd. 

2 Streinz/Michel in: Streinz, EUV/AEUV 2012, Art. 6 EUV Rn. 34. 

3 Herdegen 2016, $ 68 Rn. 33 f. 

* EuGH, NJW 1964, 2371. 

5 Ehlers in: Schulze/Zuleeg/Kadelbach 2015, $ 11 Rn. 13. 

6 EuGH, Rs. C-399/11, ECLI:EU:C:2013:107, Rn. 58 ff. 

7 Roßnagel in: Roßnagel 2017, $ 2 Rn. 5 ff. Herdegen 2016, § 10 Rn. 3; BVerfGE 126, 286 (301). 
8 RoBnagel in: RoBnagel 2017, § 2 Rn. 4. 

9 Roßnagel in: Roßnagel 2017, § 2 Rn. 5. 

!ORoßnagel in: Roßnagel 2017, § 2 Rn. 10. 
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bestehen, soweit das Unionsrecht einen Sachverhalt nicht abschließend regelt. ! 
Insbesondere kommen dafür die Öffnungsklauseln der DSGVO in Frage. 


Der Anwendungsvorrang des Unionsrechts ist im Prinzip unangefochten.? Aller- 
dings bestehen Differenzen mit den Verfassungsgerichten der Mitgliedsstaaten 
bezüglich des Verhältnisses Unionsrecht — Verfassungsrecht. Insbesondere das 
Bundesverfassungsgericht zieht Grenzen in zweierlei Hinsicht:* Die Grenze 
des Nichtübertragbaren und die Grenze des Nichtübertragenen.* 


Die Grenze des Nichtübertragbaren ist die Identität der geltenden Verfassungs- 
ordnung. Darunter fallen insbesondere die konstituierenden Strukturen der 
Bundesrepublik Deutschland und die völkerrechtliche Souveränität.” Daneben 
steht, dass bei der Übertragung von Hoheitsrechten nach Art. 23 Abs. 1 S. 1 
GG ein im wesentlichen vergleichbarer Grundrechtsschutz gewährleistet sein 
muss. Das BVerfG hat diesen bis auf weiteres für die Union festgestellt und übt 
in diesem Rahmen keine Grundrechtsprüfung mehr aus.° Es beschränkt sich 
auf eine generelle Gewährleistung der unabdingbaren Grundrechtsstandards. ’ 
Für die Datenschutzgrundrechte der Charta ist ein den deutschen Grundrechten 
vergleichbares Schutzniveau gegeben.® Deshalb ist im europäischen Bezugs- 
rahmen die Charta vorrangig. Eine Auslegung der DSGVO am Maßstab des 
Grundgesetzes ist nicht vorgesehen.” Ein möglicher Grenzfall werden die 
aus den Öffnungsklauseln der DSGVO resultierenden nationalen Regelungen 


sein. !° 


Die Grenze des Nichtiibertragenen ergibt sich aus der fehlenden Staatlichkeit 
der Union.'! Der Europäischen Union fehlt als wesentliches Merkmal der 


l Roßnagel in: Roßnagel 2017, § 2 Rn. 14. 

2 Zuleeg/Kadelbach in: Schulze/Zuleeg/Kadelbach 2015, § 8 Rn. 15; BVerfGE 123, 267 (402). 
3 BVerfGE 123, 267 (400 ff.). 

4 Ehlers in: Schulze/Zuleeg/Kadelbach 2015, § 11 Rn. 21 ff. 
5 BVerfGE 37, 271 (279); BVerfGE 123, 267 (400). 

6 BVerfGE 73, 339 (387). 

7 BVerfGE 89, 155 (175). 

8 Johannes in: Roßnagel 2017, § 2 Rn. 64. 

9 Johannes in: Roßnagel 2017, § 2 Rn. 65. 

!0Johannes in: Roßnagel 2017, § 2 Rn. 108. 

Ehlers in: Schulze/Zuleeg/Kadelbach 2015, § 11 Rn. 25. 
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Staatlichkeit ein europäisches Staatsvolk.! Sie ist eine Union der Völker 
Europas.” Des Weiteren fehlt der Union die Kompetenz zur selbstständigen 
Erweiterung ihrer Befugnisse (Kompetenz-Kompetenz).* Die Mitgliedsstaaten 
sind die „Herren der Verträge“.* Ultra-Vires-Akte sind unzulässig.” 


Dennoch ist das Grundgesetz im Grundsatz europarechtsfreundlich.® Das 
BVerfG sieht sich in einem Kooperationsverhältnis zum EuGH.’ Es erlegt 
sich selbst auf, eine Vorabentscheidung des EuGH anzustreben, bevor es eine 
Verletzung der unabdingbaren Grundrechtsstandards oder einen Ultra-Vires-Akt 
annimmt. ® 


Neben der Bundesrepublik Deutschland wird auch in anderen Mitgliedsstaaten 
der Vorrang des Unionsrechts nicht uneingeschränkt akzeptiert.” 


Wie im nationalen Verfassungsrecht ist der Schutz personenbezogener Daten 
in der Charta substantiell verankert. Das Recht auf Auskunft ist in Art. 8 
Abs. 2 Satz 2 GRCh explizit kodifiziert. Art. 16 Abs. 2 AEUV enthält die 
Kompetenz zum Erlass von Vorschriften zum Schutz natürlicher Personen bei 
der Verarbeitung personenbezogener Daten. Darauf beruht die Verabschiedung 
der DSGVO. 


Daneben finden sich, wie in der nationalen Verfassung, in der Charta in Art. 15 
die Berufsfreiheit und in Art. 16 GRCh die unternehmerische Freiheit als 


1 Herdegen 2016, § 5 Rn. 16; BVerfGE 89, 155 (184). 

2 Präambel des EUV. 

3 BVerfGE 89, 155 (192 ff.). 

4 Herdegen 2016, § 6 Rn. 1. 

5 BVerfGE 126, 286 (302 ff.). 

6 BVerfGE 123, 267 (347). 

1 BVerfGE 89, 155 (175). 

8 BVerfGE 126, 286 (304). 

9 Ehlers in: Schulze/Zuleeg/Kadelbach 2015, $ 11 Rn. 36. 
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Gegeninteressen, die in die gesetzgeberische Abwägung mit einzubeziehen 
sind.! 


EMRK und Unionsrecht Die Charta und die EMRK widersprechen sich 
nicht, sondern ergänzen sich.2 Soweit die Charta Rechte enthält, die jenen 
in der EMRK entsprechen, gleichen Bedeutung und Tragweite der Rechte in 
der Charta nach Art. 52 Abs. 3 S. 1 GRCh der Bedeutung und Tragweite der 
Rechte der EMRK. Nach Art. 52 Abs. 3 S. 2 GRCh schließt dies nicht aus, 
dass „das Recht der Union einen weiter gehenden Schutz gewährt.“ Bezogen 
auf die Datenschutzgrundrechte vertritt die Artikel-29-Datenschutzgruppe die 
Auffassung, dass Art. 8 Abs. 1 EMRK und Art. 7 und 8 GRCh die gleiche 
Bedeutung und die gleiche Tragweite haben.” Der sachliche Schutzbereich des 
Art. 8 GRCh geht allerdings über die EMRK hinaus.* 


Darüber hinaus sind nach Art. 6 Abs. 3 EUV die Grundrechte der EMRK und 
der gemeinsamen Verfassungsüberlieferung als allgemeine Grundsätze Teil des 
Rechts der Union. 


Die EMRK ist Rechtserkenntnisquelle statt Rechtsquelle des EuGH, aus der 
rechtsvergleichend die Unionsgrundrechte hergeleitet werden.° Dies gilt so 
lange die Union der EMRK noch nicht nach Art. 6 Abs. 2 S. 1 EUV beigetreten 
ist. Der EuGH sperrt sich bisher gegen einen Beitritt. Der Beitritt der Union zur 
EMRK würde der EMRK im gleichen Maße Anwendungsvorrang gegenüber 
nationalem Recht geben, wie dies für das Primärrecht der Union der Fall ist. 


Im Sekundärrecht positioniert sich der Erwägungsgrund (ErwGr) 41 DSGVO entsprechend. Er 
klassifiziert zwar das Recht auf Auskunft als ein grundlegendes Recht eines jeden Unionsbürgers, 
fordert aber zugleich die Berücksichtigung unternehmerischer Freiheiten. Insbesondere in Bezug 
auf den logischen Aufbau von IT-Systemen wird auch das Urheberrecht als Schranke aufgeführt. 
Inwieweit das Urheberrecht eine über Betriebs- und Geschäftsgeheimnisse hinausgehende 
Schutzwirkung für den logischen Aufbau von IT-Systemen bieten soll, bleibt unklar. 

? EuGH, EuZW 2010, 939 (941). 

3 Artikel-29-Datenschutzgruppe 2014, 4 f. 

4 Holznagel/Dietze in: Schulze/Zuleeg/Kadelbach 2015, § 37 Rn. 3. 

5 Streinz/Michel in: Streinz, EUV/AEUV 2012, Art. 6 EUV Rn. 25. 

6 EuGH, Gutachten 2/13, ECLI:EU:C:2014:2454. 
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Aus Sicht des EGMR ist das Grundrechtsniveau des Unionsrechts mit der 
EMRK vergleichbar.'! Der EGMR folgt der Solange-II-Rechtsprechung? des 
BVerfG.’ 


2.2.2 Das Recht auf Auskunft im Unionsrecht 


Nach Auffassung des EuGH ist das Auskunftsrecht essentiell notwendig, um 
dem Betroffenen die Wahrnehmung seiner weiteren Rechte zu ermöglichen.* 
Aus der Verankerung des Rechts auf Auskunft im Primärrecht der Union folgt, 
dass ein Fehlen des Rechts im Grundgesetz in den Bereichen, in denen die 
Union materiell zuständig ist, keine praktischen Auswirkungen hat. 


Die DSGVO ist gemäß Art. 99 am 20. Mai 2016 in Kraft getreten und gilt 
ab dem 25. Mai 2018 verbindlich und unmittelbar in jedem Mitgliedsstaat.° 
Sie wird das europäische Datenschutzrecht der Zukunft entscheidend prägen 
und gibt in den Artikeln 12 bis 15 und 20 neue Impulse für die datenschutz- 
rechtliche Transparenzverfassung. Das eigentliche Auskunftsrecht bleibt im 
Grundsatz gleich. Seine Ausgestaltung weicht nur in wenigen Aspekten von der 
Umsetzung der DSRL durch das BDSG ab. Diese Aspekte werden in Kapitel 3 
themenbezogen mitbehandelt. Die in dieser Arbeit auf Grundlage des BDSG 
getroffenen, fundamentalen Aussagen zum Auskunftsrecht dürften wegen der 
vergleichbaren Rechtslage unter der DSGVO auch europaweit Geltung haben. 


Das neuartige Recht auf Datenübertragbarkeit in Art. 20 DSGVO wird in Ka- 
pitel 10.2 gesondert beleuchtet. Sein innovativer Charakter macht, abweichend 
vom übrigen Vorgehen, eine herausgehobene Erörterung zukünftigen Rechts 
notwendig. 


Gegenwärtig ist die DSRL noch der sekundärrechtliche Rahmen des EU- 
Datenschutzrechts für die einfachgesetzliche Umsetzung im nationalen Recht. 


! Herdegen 2016, $ 3 Rn. 62. 

? BVerfGE 73, 339 (387). 

3 EGMR, NJW 2006, 197 (203). 
4 EuGH, EuZW 2009, 546 (548). 
5 Vel. Art. 288 AEUV. 
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In Art. 12 wird das Recht auf Auskunft kodifiziert. In Art. 13 werden mögliche 
Ausnahmeregelungen aufgezeigt, die der nationale Gesetzgeber wahrnehmen 
kann. Ob das BDSG europäisches Recht richtlinienkonform umsetzt, wird in 
den nachfolgenden Kapiteln diskutiert. 


2.3 Zwischenfazit 


Das Recht auf Auskunft ist entgegen der Annahme aus Hypothese 91 kein 
generell verfassungsrechtlich gebotenes Betroffenenrecht. Das vom Bundesver- 
fassungsgericht aus dem Recht auf informationelle Selbstbestimmung abge- 
leitete Recht auf Kenntnisnahme führt allerdings zum gleichen Schutzniveau 
ohne den Gesetzgeber in der Realisierung des Transparenzgedankens für die 
Zukunft einzuschränken. 


Fraglich ist, welchen Stellenwert das Recht auf Kenntnisnahme in Zukunft noch 
haben wird. Mit dem in Art. 8 Abs. 2 Satz 2 der Charta explizit kodierten Recht 
auf Auskunft wurde auf europäischer Ebene eine starke Festlegung getroffen. 
Vermittels der DSGVO wird die Bedeutung der nationalen Grundrechte weiter 
zurückgehen. Der EuGH wird das Datenschutzrecht maßgeblich mitprägen. 


Wie sich das Bundesverfassungsgericht nach Solange I,' Solange II,” dem 
Maastricht-Urteil? und der Lissabon-Entscheidung* positioniert, bleibt offen. 
Einer Konkretisierung des Rechts auf Kenntnisnahme durch die Verträge, die 
Charta und die Rechtsprechung des EuGH wird es wohl nicht entgegentreten. 


l BVerfGE 37, 271. 
2 BVerfGE 73, 339. 
3 BVerfGE 89, 155. 
4 BVerfGE 123, 267. 
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Rechts auf Auskunft 


„Das Auskunftsrecht ist für die Betroffenen das fundamentale Datenschutz- 
recht.“! Es wird sogar als die „Magna Charta des Datenschutzes“ bezeichnet.” 
Es ist gemäß $ 6 Abs. 1 BDSG unabdingbares Recht des Betroffenen und 
kann nicht ausgeschlossen oder beschränkt werden. Das Auskunftsrecht ist 
die Voraussetzung zur Wahrnehmung der übrigen Betroffenenrechte auf Lö- 
schung, Sperrung und Berichtigung. Es ist die wirksamste Ausprägung des 
datenschutzrechtlichen Transparenzgebots.* 


Das Auskunftsrecht kombiniert Selbstdatenschutz* (Kontrollrecht des Einzel- 
nen) und externe Kontrolle. Es ist ein Element des ersteren und ermöglicht 
damit letzteres. 


Dieses Kapitel diskutiert und beleuchtet die Einbindung des Rechts auf Aus- 
kunft in die Systematik des Datenschutzrechts (Abschnitt 3.1), Aspekte der 
Auskunftserteilung und der Reichweite des Auskunftsrechts (Abschnitt 3.2 bis 
3.4) sowie den Umfang des Auskunftsanspruchs (Abschnitt 3.6 bis 3.8).° Er- 
gänzend zu den Vorschriften des BDSG wird, wo erforderlich, themenbezogen 
auf grundrechtliche Aspekte sowie die bestehende (DSRL) und kommende 
(DSGVO) Rechtslage der Europäischen Union eingegangen. 


l Dix in: Simitis, BDSG 2014, § 34 Rn. 1. 

2 Neben anderen Wedde in: Roßnagel 2003, Kap. 4.4 Rn. 2; Dix in: Simitis, BDSG 2014, $ 34 Rn. 
1; Weichert, DuD 2006, 694 (694). 

3 Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 48. 

4 RoBnagel in: Roßnagel 2003, Kap. 3.4 Rn. 1 ff. 

5 Eine Zusammenfassung dieses Kapitels wurde bereits in Bier, DuD 2015, 741 veröffentlicht. 
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3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


3.1 Einbindung des Rechts auf Auskunft in die 
Systematik des Datenschutzrechts 


Verwendung personen- 
bezogener Daten Transparenz Intervention 


c Unverkettbarkeit + Verantwortlichkeit + Kontrolle durch 
po Datensparsamkeit 
g (Datenminimierung) . Aufsichtsbehörde 
S Zweckbindung +  Nicht-automatisierte 
Vertraulichkeit Einzelentscheidung 
> Datensicherheit 
Datengeheimnis Information Auskunft * Berichtigen 
I + Hinweis + Daten + Sperren 
S « Unterrichtung « Herkunft * Löschen 
© | (Erhebung beim + Empfanger 
x Betroffenen) + System- 
wW I * Benachrichtigung aufbau 
(Erhebung bei I 
I Dritten) 
Integrität | der PB-Daten der Auskunft der Berechtigung 
Verfügbarkeit | der PB-Daten der Information / Rechtzeitigkeit des Ansprechpartners 
Abstrakte Forderungen Betroffenenrecht: Betroffenenrecht: 
an den Datenverwender: Beurteilen können, Selbst bestimmen können, 
Möglichst wenige Daten wer wann was über mich weiß wer wann was über mich weiß 
Möglichst richtige/gute Daten + Privatautonomie 


Möglichst eng gefasste Verwendung 
Möglichst eng gefasster Nutzerkreis 


Abbildung 3.1: Struktogramm Datenschutz (mit angedeuteter Abfolge der Bausteine) 


Die datenschutzrechtlichen Vorschriften können in drei wesentliche Bausteine 
untergliedert werden: Den datenschutzgerechten Umgang mit personenbe- 
zogenen Daten, die Transparenz darüber und die darauf aufbauenden Inter- 
ventionsmöglichkeiten (Abbildung 3.1). Transparenz und Intervenierbarkeit 
haben jeweils eine interne und eine externe Komponente. Interne Transpa- 
renz wird über Verfahrensverzeichnisse und Datenschutzaudits ($ 9a BDSG) 
hergestellt. Externe Transparenz entsteht vor allem durch ein umfangreiches 
Informationsangebot nach außen hin. Intervenierbarkeit manifestiert sich intern 
im Verbot der automatischen Einzelentscheidung ($ 6a BDSG), extern durch 
umfangreiche Gestaltungsrechte des Betroffenen (§ 35 BDSG). 
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3.1 Einbindung des Rechts auf Auskunft in die Systematik des Datenschutzrechts 


Die datenschutzgerechte Erhebung, Verarbeitung und Nutzung personenbezo- 
gener Daten ist die Grundlage auf der alle Betroffenenrechte aufsetzen. Sie ist 
Schwerpunkt der Datenschutzziele! Integrität, Verfügbarkeit und Vertraulich- 
keit (siehe dazu auch Kapitel 4.1 2)? 


Transparenz ist die Voraussetzung für die Wahrnehmung weiterer Kontroll-, 
Abwehr- und Gestaltungsrechte.? Der Transparenzgedanke der EU- 
Datenschutzrichtlinie, die auch das Bundesdatenschutzgesetz prägt, verlangt 
schon bei der Erhebung eine umfangreiche Information des Betroffenen. * 


An erster Stelle stehen deshalb Hinweis- und Kennzeichnungspflichten. Geübte 
Praxis ist die Kennzeichnung durch Hinweisschilder im Umfeld der Video- 
überwachung ($ 6b Abs. 2 BDSG) und durch ein digitales Äquivalent in der 
Umsetzung der EU-Cookie-Richtlinie.° Ebenso zählt die bei der Einwilligung 
erforderliche Belehrung ($ 4a Abs. 1 S. 2 BDSG) zu den einer Erhebung 
vorausgehenden Hinweispflichten. Hinweis- und Kennzeichnungspflichten sind 
unabhängig von einer tatsächlichen Erhebung personenbezogener Daten bei 
jedem Einzelnen, der den Hinweis wahrnimmt. Sie sollen vor der potentiellen 
Erhebung warnen, ihren Zweck darlegen und über die Folgen der Erhebung und 
anschließenden Verwendung aufklären. Der Betroffene hat dann die Möglich- 
keit schon auf den Erhebungsvorgang selbst einzuwirken. Wie beispielsweise 
bei Videoüberwachungsanlagen finden sie meistens dort Anwendung, wo Da- 
ten über eine unspezifische und nicht ohne weiteres zu benennende Menge 
an Personen erhoben werden. Teil eines Hinweises vor der Erhebung perso- 
nenbezogener Daten ist auch die Erläuterung einer eventuellen gesetzlichen 
Auskunftsverpflichtung des Betroffenen ($ 4a Abs. 1 S. 2 BDSG) und eine 
Aufklärung über mögliche Folgen einer Verweigerung der Datenerhebung 
(§ 4a Abs. 1 S. 2 BDSG). 


Die Unterrichtung ist das geeignete Instrument zur Information des Betroffenen 
nach der Erhebung personenbezogener Daten bei ihm selbst (§ 4 Abs. 3 S. 1 


l In § 5 Abs. 1 LDSG-SH verankert. 

? Rost/Bock, DuD 2011, 30 (32). 

3 Mallmann in: Simitis, BDSG 2014, § 19 Fn. 1. 

4 Dix in: Simitis, BDSG 2014, § 34 Rn. 4. 

5 Art. 5 Abs. 3 ePrivacy-RL in der durch die Cookie-RL geänderten Fassung. 
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BDSG). Sie ist spezifisch auf einen tatsächlich vorgenommenen Erhebungs- 
vorgang hin gemünzt und soll den Betroffenen dann über die Erhebung und 
ihre Umstände informieren, wenn er von ihr nicht selbst hat Kenntnis nehmen 
können und sie nicht zumindest nach dem im Geschäftsverkehr üblichen zu er- 
warten hatte. ! Digital findet man sie als Datenschutzerklärungen auf Webseiten 
(§ 13 Abs. 1 TMG). 


Die Benachrichtigung (§§ 19a, 33 BDSG) ist das Gegenstück bei der Erhebung 
personenbezogener Daten bei Dritten. Sie gibt dem unbeteiligten Betroffenen 
die Möglichkeit der Kenntnisnahme. Sie flankiert damit den Hinweis und 
die Unterrichtung in der Ermächtigung (Empowerment) des Betroffenen zu 
weiteren Schritten. Benachrichtigung und Unterrichtung sind Spielarten der 
aktiven Transparenz und gehen von der verantwortlichen Stelle aus. Sie sind 
Bringschuld der verantwortlichen Stelle. Gemeinsam schaffen sie die Voraus- 
setzung dafür, dass der Betroffene im zweiten Schritt selbst aktiv wird und 
ein Auskunftsersuchen stellt.” Die Brücke zwischen beiden Transparenzarten 
kann beispielsweise die Vergabe von Schlüsselkennungen (Credentials) bilden. 


Die Auskunft (§§ 19, 34 BDSG) ist als passive Transparenzmaßnahme Hol- 
schuld des Betroffenen. ° Sie ist dort Auffangrecht für den Betroffenen, wo die 
übrigen Transparenzregelungen lückenhaft sind.* 


Die Übersicht für Jedermann nach $ 4g Abs. 2 S. 21. V.m. § 4e S. 1 Nr. 1 bis 
8 BDSG steht strukturell zwischen den Hinweispflichten und der Auskunft. 
Sie ist einerseits wie die Hinweispflichten unabhängig von der Betroffenen- 
eigenschaft und macht ausschließlich allgemeine Informationen zugänglich. 
Sie ist andererseits wie die Auskunft Holschuld der interessierten Person, 
wogegen Hinweise und Kennzeichen so angebracht werden müssen, dass sie 
ein potentiell Betroffener mit großer Sicherheit wahrnehmen kann. Die Über- 
sicht für Jedermann ist nicht nur potentiell Betroffenen, natürlichen Personen, 


! Im Besonderen ist sie deshalb als Maßnahme bei mobilen personenbezogenen Speicher- und 
Verarbeitungsmedien in $ 6c Abs. 1 BDSG zu finden. 

2 Meents/Hinzpeter in: Taeger/Gabel, BDSG 2013, BDSG § 34 Rn. 1. 

3 Dix in: Simitis, BDSG 2014, § 34 Rn. 6. 

4 Weichert, DuD 2006, 694 (694). 

5 Scholz in: Simitis, BDSG 2014, § 6b Rn. 107. 


52 


3.2 Reichweite des Rechts auf Auskunft 


sondern auch juristischen Personen zugiinglich.! Die Übersicht für Jedermann 
führt weder zu einer Erleichterung des Zugangs zur Auskunft, noch kann sie 
Auskunftsersuchen Betroffener in irgendwie gearteten Fällen erledigen.” Sie 
erscheint nicht nur deshalb als ein bürokratisches Relikt.* 


Stellt der Betroffene Ungereimtheiten in den über ihn gespeicherten Daten 
oder die Unrechtmäßigkeit der Verarbeitung fest, kann er im Folgeschritt seine 
Interventionsrechte wahrnehmen. Bei einer Integration in ein interaktives 
Auskunftssystem kann er in einem direkten Folgeschritt die Berichtigung ($ 20 
Abs. 1, § 35 Abs. 1 BDSG), Löschung (S 20 Abs. 2, $ 35 Abs. 2 BDSG) oder 
Sperrung (§ 20 Abs. 3, 4 u. 6, § 35 Abs. 3 u. 4 BDSG) der Daten anordnen und 
ihrer weiteren Verwendung widersprechen ($ 20 Abs. 5, $ 35 Abs. 5 BDSG). 


Die Systematik der Transparenzregelungen bleibt im Rahmen der zukünftigen 
DSGVO grundsätzlich gleich.* Allerdings kommt das Recht auf Datenüber- 
tragbarkeit in Art. 20 DSGVO als Neuschöpfung hinzu.’ 


3.2 Reichweite des Rechts auf Auskunft 


Auskunft meint im Rahmen dieser Arbeit immer den datenschutzrechtlichen 
Auskunftsanspruch als Recht des Betroffenen aus $ 19, 34 BDSG und ver- 
wandten Spezialgesetzen.° Die Auskunftspflicht der verantwortlichen Stelle 
gegenüber der Aufsichtsbehörde ($ 38 Abs. 3 BDSG) oder anderen Behörden”? 
ist nicht Teil dieser Diskussion.® Außen vor ist auch die Verpflichtung des 


l Scheja in: Taeger/Gabel, BDSG 2013, BDSG § 4g Rn. 33. 

2 A.A. Gola/Schomerus, BDSG 2015, § 4g Rn. 25 

3 Scheja in: Taeger/Gabel, BDSG 2013, BDSG § 4g Rn. 34. 

4 Unterrichtung in Art. 13 DSGVO, Benachrichtigung in Art. 14 DSGVO, Auskunft in Art. 15 
DSGVO, Berichtigung in Art. 16 DSGVO, Léschung in Art. 17 DSGVO, Sperrung in Art. 18 
DSGVO, Widerspruch in Art. 21 DSGVO. 

5 Siehe Kapitel 10.2. 

6 U.a. § 13 TMG, § 93 TKG, § 83 SGB X. 

7 Beispielsweise gemäß § 110 ff. TKG gegenüber Sicherheitsbehérden. 

8 Die Ubermittlung an Dritte nach § 28 Abs. 2 Nr. 2 BDSG wird ebenfalls nicht einbezogen. Siehe 
zur entgegenstehenden Zweckbindung auch BGH, DuD 2014, 715 (716). 
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Betroffenen zur Auskunft aufgrund einer Rechtsvorschrift entsprechend § 4 
Abs. 3 S. 2 BDSG. 


Auch zivil-! sowie gesellschaftsrechtliche? Ansprüche des Betroffenen bleiben 
unberücksichtigt. Zivilrechtliche Ansprüche können im Gegensatz zu daten- 
schutzrechtlichen Ansprüchen gegenüber jedem Privaten durchgesetzt werden. 
Sie sind Rechte unter gleichen. Der datenschutzrechtliche Auskunftsanspruch 
gleicht dagegen ein informationelles Machtgefälle aus. Der Umgang mit per- 
sonenbezogenen Daten aus einer rein persönlichen oder privaten Tätigkeit 
heraus ist deshalb nach $ 1 Abs. 2 Nr. 3 BDSG vom datenschutzrechtlichen 
Auskunftsanspruch ausgenommen. 


Auskunftsverpflichtete ist die verantwortliche Stelle. Der Anwendungsbereich 
des $ 34 BDSG bestimmt sich grundsätzlich nach $ 27 BDSG und erstreckt 
sich damit auf nicht-Öffentliche Stellen und öffentlich-rechtliche Wettbewerbs- 
unternehmen des Bundes und (mit Einschränkungen) der Länder ($ 27 Abs. 1 
S. 1 Nr. 1 u. 2 BDSG) soweit mit personenbezogenen Daten umgegangen wird 
(§ 27 Abs. 1 S. 1 BDSG).? Der Anwendungsbereich des $ 19 BDSG folgt dem 
des $ 12 BDSG. Er bezieht sich auf den Umgang mit personenbezogenen Daten 
durch öffentliche Stellen des Bundes ($ 12 Abs. 1 BDSG). Weil mittlerweile 
alle Länder eigene Datenschutzgesetze besitzen, spielt $ 12 Abs. 2 BDSG keine 
Rolle mehr. 


Der Gesetzgeber hat den Auskunftsanspruch des Betroffenen im BDSG ein- 
schließlich etwaiger Spezialgesetze abschließend geregelt. Deshalb kann ein 
Auskunftsersuchen grundsätzlich nicht mit dem allgemeinen Persönlichkeits- 
recht begründet werden.* 


Die einzige Voraussetzung der Auskunftserteilung ist ein Auskunftsverlangen 
durch den Betroffenen. Das Auskunftsverlangen unterliegt selbst keinerlei 
Voraussetzung. Insbesondere muss es nicht begründet werden und bedarf 


1 §§ 259, 260, 402, 666, 1004, 1379, 1580, 1605, 1799, 1839, 2027, 2057, 2127, 2314 BGB. 

? § 131 AktG; § 5la GmbHG. 

3 Erheben, Verarbeiten und Nutzen von Daten unter Einsatz von Datenverarbeitungsanlagen oder 
in/aus nicht automatisierten Dateien. 

4 BGH, NJW 1984, 1886 (1886). 
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keines Zweckes oder Anlasses. Auch ein berechtigtes Interesse muss nicht 
dargelegt werden. ! 


3.3 Form und Inhalt des Auskunftsersuchens 


Es besteht keinerlei Formerfordernis an das Auskunftsersuchen selbst.” Das 
Verlangen kann schriftlich, in Textform oder miindlich an die verantwortliche 
Stelle gerichtet werden. Es steht dem Betroffenen auch frei, ob er sich elektro- 
nisch per E-Mail oder Webformular oder analog an die verantwortliche Stelle 
wendet. Die verantwortliche Stelle hat zumindest die Kommunikationskanäle 
offen zu halten, auf denen sie auch selbst mit Dritten kommuniziert.? Ver- 
wendet die verantwortliche Stelle E-Mails zur werbenden Ansprache, muss 
sie auch sicherstellen, dass eine E-Mailadresse, unter der sie erreichbar ist, 
öffentlich bekannt ist. Die internen Prozesse der verantwortlichen Stelle müssen 
so organisiert sein, dass auf allen Kanälen eingehende Auskunftsverlangen 
bearbeitet werden können. Diesbezüglich obliegt es der verantwortlichen Stelle, 
die eigenen Mitarbeiter, insbesondere Kundenservice, Vertrieb, und Empfang, 
angemessen zu schulen. Ein intern einheitlicher Ansprechpartner, wie der 
betriebliche oder behördliche Datenschutzbeauftragte, ist nicht von außen her 
verpflichtend zu kontaktieren. 


Gemäß § 6 Abs. 2 S. 2 BDSG kann sich der Betroffene sogar an eine andere 
als die speichernde Stelle wenden, sofern bei einer verteilten automatisierten 
Verarbeitung nicht ersichtlich ist, welche Stelle speichert. Die kontaktierte 
Stelle ist dann verpflichtet, das Auskunftsersuchen an die speichernde Stelle 
weiterzuleiten. 


Die nach $ 34 Abs. 1S.2 BDSG zu erfolgende nähere Bezeichnung der Art per- 
sonenbezogener Daten, die beauskunftet werden sollen, ist eine Sollvorschrift. 


! Dix in: Simitis, BDSG 2014, $ 34 Rn. 12. 

2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 13; Gola/Schomerus, BDSG 2015, $ 34 Rn. 1. 

3 So auch die DSGVO: Werden personenbezogene Daten elektronisch verarbeitet, sollte gemäß 
ErwGr 59 eine elektronische Antragstellung möglich sein. 
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Die nähere Bezeichnung ist nicht Voraussetzung für die Auskunftserteilung. 
Das Auskunftsersuchen darf nicht aufgrund fehlender Präzision verweigert 
werden. ! 


Da nur Betroffene ein Recht auf Auskunft haben, ist für eine gerichtliche 
Geltendmachung des Rechtes ausreichend darzulegen, dass personenbezo- 
gene Daten von einer verantwortlichen Stelle verwendet wurden. Es ist kein 
Erwirken der gerichtlichen Durchsetzung „ins Blaue hinein“ möglich.” Die 
Auskunftsansprüche und ihre Begründung müssen im Sinne des $ 253 Abs 2 
Nr. 2 ZPO hinreichend präzisiert werden.’ 


Die Ausführungen zum BDSG haben unter der DSGVO weiterhin Geltung. 
Die Rechtslage ändert sich im Wesentlichen nicht. Allerdings führt Art. 26 
DSGVO den Begriff des gemeinsam für die Verarbeitung Verantwortlichen als 
neue Rechtsfigur ein. Verarbeiten mehrere Stellen personenbezogene Daten im 
Verbund und legen gemeinsam die Zwecke der Verarbeitung fest, können sie 
intern, aber in für den Betroffenen transparenter Form, regeln, wer welchen 
Teil der Informationspflichten nach Art. 13 und 14 DSGVO erfüllt. In der 
Vereinbarung kann ein einheitlicher Ansprechpartner für den Betroffenen 
festgelegt werden. Eine Vereinbarung nach Art. 26 DSGVO hat wie gehabt 
keine Außenwirkung (Abs. 3). Der Betroffene ist nicht verpflichtet die benannte 
Stelle zu kontaktieren, sondern kann sich weiterhin an jede verantwortliche 
Stelle wenden. Die Bestimmungen des Art. 26 DSGVO sollen jedoch zukünftig 
dazu führen, dass Auskunftsanfragen effizienter und für den Betroffenen im 
Regelfall schneller beantwortet werden können. 


Einschränkend kann eine verantwortliche Stelle in Zukunft gemäß ErwGr 63 
DSGVO verlangen, dass bei einer Vielzahl gespeicherter personenbezogener 
Daten die gewünschten Daten präzisiert werden. Der Betroffene kann jedoch 


! Dix in: Simitis, BDSG 2014, $ 34 Rn. 41; Gola/Schomerus, BDSG 2015, $ 34 Rn. 5; Me- 
ents/Hinzpeter in: Taeger/Gabel, BDSG 2013, BDSG § 34 Rn. 15. 

2 Gola/Schomerus, BDSG 2015, $ 34 Rn. 5a; Landgericht München II, Urteil vom 20.09.2005, 
MMR Heft 12, XXIII (Kurzinformation). 

3 LAG Hessen, Urteil vom 29.01.2013, BeckRS 2013, 67364. 
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weiterhin antworten, dass er gerne alle Daten hätte.! Die nähere Bezeichnung 
bleibt optional. 


3.4 Der Auskunftsberechtigte und dessen 
Identifizierung 


Das Recht auf Auskunft steht allen Betroffenen zu — unabhängig von Alter, 
Nationalität und Wohnsitz. Es gibt jedoch kein Auskunftsrecht für Dritte. 
Eine Weitergabe personenbezogener Daten an Dritte ist eine Übermittlung. ? 
Ihrem Regelungsgehalt nach, und da die Auskunft ein Auskunftsverlangen des 
Betroffenen voraussetzt, kann die verantwortliche Stelle diese Übermittlung 
personenbezogener Daten an Dritte niemals auf das Auskunftsrecht stützen. 
Der Antrag auf Auskunft kann allerdings durch einen Bevollmächtigten des 
Betroffenen gestellt werden.” In diesem Fall ist durch die verantwortliche Stelle 
die Vollmacht gesondert zu prüfen. 


Anders sieht es für die Rechtsnachfolge der Erben aus. Sie können grundsätz- 
lich keinen Auskunftsanspruch geltend machen, da das Auskunftsrecht ein 
höchstpersönliches Recht ist.* Nichtsdestoweniger wird vertreten, dass das 
Auskunftsrecht auf den Erben übergeht, da die Daten nach Tod des Erblassers 
ansonsten komplett schutzlos wären.’ Diese Ansicht verkennt indes, dass 
nicht Daten, sondern die Persönlichkeitsrechte des Betroffenen das Schutzgut 
des Datenschutzes sind. Das postmortale Persönlichkeitsrecht ist jedoch auf 
den eng gefassten Schutzbereich der Menschenwürde aus Art. 1 Abs. 1 GG 
reduziert.° Mit dem postmortalen Würdeschutz wird der Achtungsanspruch 
des Verstorbenen gegen Verobjektivierung und Herabwürdigungen nach dem 


! Laue/Nink/Kremer 2016, § 4 Rn. 27. 

2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 14. 

3 Mallmann in: Simitis, BDSG 2014, $ 19 Rn. 34. 

4 Dix in: Simitis, BDSG 2014, $ 34 Rn. 43; Klas/Möhrike-Sobolewski, NJW 2015, 3473 (3474) 
5 Solmecke/Kébrich/Schmitt, MMR 2015, 291 (293). 

6 BVerfGE 30, 173 (194). 
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Tode geschützt.! Das Andenken des Verstorbenen ist geschützt, ein Missbrauch 
seiner Daten zur Verunglimpfung ist unzulässig.” Ein Datenschutzrecht auf 
Auskunft der Erben ergibt sich jedoch nicht. 


Vermögensrechtliche Ansprüche auf Auskunft aus Vertrag i. V.m. $ 1922 Abs. 
1 BGB stehen unabhängig daneben.” Sie erstrecken sich auch auf den nicht- 
vermögensrechtlichen Teil des Erbes.* Der Auskunftsanspruch aus Vertrag 
findet seine Grenzen im postmortalen Persönlichkeitsrecht des Erblassers. 
Soweit es sich beim Erblasser um einen Minderjährigen handelt, steht es 
dem Auskunftsanspruch der Erziehungsberechtigten als mögliche Erben und 
Sachverwalter des Persönlichkeitsrechts nicht entgegen.” 


Ob eine grundsätzliche Pflicht zur Feststellung der Identität des Auskunftsersu- 
chenden besteht, ist in der Literatur umstritten.° Aufgrund des bußgeldbewehr- 
ten Verbots der unbefugten Übermittlung personenbezogenen Daten an Dritte,” 
liegt es in jedem Fall im Interesse der verantwortlichen Stelle, die Identität 
des Auskunftsersuchenden gegen den eigenen Datenbestand zu prüfen. Die 
Intensität der Prüfung hängt von der Sensitivität der gespeicherten Daten ab 
und ist mit dieser in ein sinnvolles Verhältnis zu setzen.® 


Für die Zuordnung der gespeicherten Daten zu der auskunftsersuchenden Person 
ist gegebenenfalls die Einholung ergänzender Informationen erforderlich ($ 34 
Abs. 1 S. 2 BDSG). Die Auskunft darf nicht unter dem Vorwand abgelehnt 
werden, dass kein Name und keine Kontaktadresse des Betroffenen gespeichert 
ist.” Nur wenn nach Einholung weiterer Informationen die Zuordnung zu einem 
bestimmten Betroffenen nicht möglich ist entfällt die Auskunftspflicht. In 


! Dreier in: Dreier, GG 2013, Art. 1 Abs. 1 Rn. 76. 

2 Strafrechtlicher Schutz in § 189 StGB; darüber hinausgehend § 4 Abs. 1 S. 2 BInDSG. 

3 Klas/Möhrike-Sobolewski, NJW 2015, 3473 (3478). 

4 LG Berlin, ZD 2016, 182 (183) = MDR 2016, 165 (165). 

5 LG Berlin, ZD 2016, 182 (184). 

6 Dix in: Simitis, BDSG 2014, $ 34 Rn. 43 m. w. N. Gola/Schomerus, BDSG 2015, § 34 Rn. 6 für 
eine Prüfungspflicht mit der im Verkehr erforderlichen Sorgfalt. 

7 843 Abs. 2 Nr. 1 i. V.m. Abs. 3 S. 1 BDSG. 

8 Heinemann/Wäßle, MMR 2010, 600 (603). 

9 Dix in: Simitis, BDSG 2014, $ 34 Rn. 14. 
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diesem Falle handelt es sich zumindest subjektiv nicht um personenbezogene 
Daten (relativer Personenbezug). 


Müsste der Betroffene die über ihn gespeicherten Daten jedoch voll umfänglich 
nennen, um zu seinem Recht auf Auskunft zu kommen, würde die Intention des 
Anspruchs pervertiert. Denn die Auskunft soll ja gerade erst dem Betroffenen 
jene Einblicke in die Speicherung und Weitergabe gewähren, die er bisher nicht 
hatte. Sie soll auch bei bisher nicht bekanntem Umgang mit personenbezoge- 
nen Daten für Transparenz sorgen. Daraus entsteht eine Fürsorgepflicht der 
verantwortlichen Stelle gegenüber dem Betroffenen, die Daten so zu erheben, 
zu speichern und zu verwenden, dass eine vollständige Beauskunftung im 
Nachhinein noch möglich bleibt. 


Diese Fürsorgepflicht entspricht den Interessen des Betroffenen und bildet 
1. V.m. $ 31 BDSG die Grundlage für eine Speicherung von Herkunft, Emp- 
fänger und Identifikatoren über den eigentlichen Zweck der Basisdaten hinaus 
(siehe auch Abschnitt 3.6). Eine ergänzende Erhebung personenbezogener 
Daten ist jedoch ausgeschlossen.! Es geht darum, die Struktur der Ablage 
personenbezogener Daten so zu gestalten, dass der Personenbezug nicht nur bei 
der Verwendung durch die verantwortliche Stelle, sondern auch im Zuge der 
Auskunft herstellbar ist. Dies gilt insbesondere bei pseudonym gespeicherten 
Daten. 


Die spezialgesetzliche Regelung des $ 13 Abs. 7 TMG verpflichtet explizit zu 
einer Auskunftserteilung über zu einem Pseudonym gehörende personenbezo- 
gene Daten. Ein entsprechendes Auskunftsersuchen kann im Geltungsbereich 
des TMG allein über das Pseudonym stattfinden, ohne die eigentliche Identität 
preiszugeben. Die Authentizität des Pseudonymverwenders kann am besten 
mit Hilfe eines gemeinsamen Geheimnisses überprüft werden.” Diese vor- 
ausschauende Regelung für die digitalen Telemedien lässt erkennen, wie eine 
zukünftige automatisierte Auskunft generell ausgestaltet werden könnte. 


! BVerfGE 109, 279 (365). 
? Dix in: Simitis, BDSG 2014, $ 34 Rn. 45. 
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In Situationen, in denen personenbezogene Daten nicht mit einem authentifi- 
zierbaren Pseudonym, einem Berechtigungsnachweis (Credential) oder einem 
anderen eindeutigen Identifikator verknüpft werden können oder solch ei- 
ne Verknüpfung den Interessen des Betroffenen widersprechen würde, kann 
kein vollständiger Auskunftsanspruch gewährleistet und gerechtfertigt werden. 
Wurden Daten vom Betroffenen oder einem Dritten erhoben oder an den Be- 
troffenen oder einen Dritten weitergegeben, und sind diese Vorgänge nur einem 
eingeschränkten Personenkreis bekannt, kann ein Bezug auf diese Vorgänge 
als ergänzende Information für ein Auskunftsersuchen ausreichen. Damit lässt 
sich jedoch keine vollständige Auskunft erreichen, sondern nur solch eine, die 
die mit dem Vorgang verknüpften Daten umfasst. 


Die Identifizierung des Auskunftsberechtigen wird in der DSGVO den selben 
Stellenwert haben, wie im BDSG. In Art 12 Abs. 6 bestimmt die DSGVO, 
dass bei begründeten Zweifeln über die Identität des Betroffenen zusätzliche 
Informationen zur Identitätsfeststellung eingeholt werden können. Kann die 
verantwortliche Stelle den Betroffenen mit bereits gespeicherten Daten nicht 
identifizieren, so ist sie nach ErwGr 57 allerdings nicht verpflichtet, weitere 
Informationen einzuholen. Die verantwortliche Stelle darf sich jedoch nicht 
weigern, solche Informationen anzunehmen, soweit sie ihr vom Betroffenen 
übermittelt werden. Vor einer Auskunft hat die verantwortliche Stelle nach 
ErwGr 64 alle vertretbaren Mittel, insbesondere Online-Kennungen, zu nutzen, 
um die Identität des Auskunftsersuchenden zu überprüfen und sicherzustellen. 
Eine präventive Speicherung von Identifikationsmerkmalen, allein für den 
Zweck der Auskunft, sollte sie indessen nicht vornehmen. 


3.5 Art und Weise der Auskunftserteilung 


Die Auskunft hat umfassend zu erfolgen. Eine unvollständige oder unrichtige 
Auskunft ist nach $ 43 Abs. 1 Nr. 8a i. V. m. Abs. 3 S. 1 BDSG bußgeldbewehrt. 
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3.5 Art und Weise der Auskunftserteilung 


Eine Differenzauskunft! ist nur bei Einwilligung des Betroffenen zulassig.” Sie 
wiirde den Betroffenen sonst tiberproportional belasten. Unter Beriicksichtigung 
möglicher Assistenzsysteme für Betroffene, die Differenzauskünfte auf Seiten 
des Betroffenen zu einer einheitlichen Auskunft zusammenfiigen, kann unter 
Einwilligung des Betroffenen eine Differenzauskunft dennoch fiir beide Seiten 
die ökonomischere Lösung sein. Der Auskunftsanspruch umfasst alle Daten, 
also auch die Daten, von denen der Betroffene bereits weiß, dass sie bei der 
verantwortlichen Stelle gespeichert sind.” 


Bei Zweifel bezüglich der Vollständigkeit besteht vor Gericht die Möglichkeit 
der Verurteilung auf Erklärung der Vollständigkeit der Auskunft an Eides statt.* 


Die Auskunft hat unverzüglich, ohne schuldhaftes Zögern (§ 121 Abs. 1 S. 1 
BGB) zu erfolgen. Die im Geschäftsverkehr üblichen Fristen müssen allerdings 
eingeräumt werden." Lediglich besondere Umstände lassen längere Fristen zu.° 


Eine Fristbestimmung, wie sie beispielsweise im irischen Datenschutzrecht’ 
oder in der DSGVO® zu finden ist, findet sich im deutschen Datenschutzrecht 
bisher nicht. Die Auskunft ist jedenfalls innerhalb solch einer Zeitspanne 
zu erteilen, die es ermöglicht, den Zweck des Auskunftsersuchens noch zu 
erreichen. Falls eine besondere Dringlichkeit vorliegt, hat der Auskunftsbe- 
rechtigte darauf hinzuweisen. Die verantwortliche Stelle hat dann im Rahmen 
der Verhältnismäßigkeit zu prüfen, ob ihr eine entsprechende Beschleunigung 
der Bearbeitungsvorgänge zumutbar ist. 


Eine Differenzauskunft ist eine Auskunft über die Änderungen im Bestand der gespeicherten 

Daten und über neu hinzugekommene Datenweitergaben seit der letzten Auskunft. Sie stellt das 

Delta zwischen einer vollständigen Auskunft und den bereits erfolgten Auskünften dar. Sie ist 

einem inkrementellen Backup von der Funktionsweise her ähnlich. 

2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 21; a. A. siehe Fn. 53, 54 a. a. O. 

3 Gola/Schomerus, BDSG 2015, $ 19 Rn. 4; a. A. LAG Hessen, Urteil vom 29.01.2013, BeckRS 
2013, 67364. 

* AG Geislingen, RDV 2004, 178. 

5 Gola/Schomerus, BDSG 2015, $ 34 Rn. 16. 

6 Dix in: Simitis, BDSG 2014, $ 34 Rn. 42. 

7 40 Tage — Abschnitt 4 (1) (a) Irish Data Protection Act, 1988. 

8 1 Monat - Art. 12 Abs. 2 S. 1 DSGVO; mit einer Verlängerungsmöglichkeit um weitere 2 Monate 

bei komplexen Anträgen oder einer Vielzahl weiterer Anträge. 
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Auch wenn der Betroffene keine terminlichen Zwänge vorbringen kann, hat er 
in jedem Fall das Recht auf eine ziigige Bearbeitung nach Treu und Glauben. 
Der vorgeschlagene Rahmen bewegt sich von wenigen Tagen bis zu 3 Monaten. 


Die Auskunft ist nach $ 34 Abs. 8 und $ 19 Abs. 7 BDSG unentgeltlich. 
Ausnahmeregelungen gibt es allein für Auskunfteien ($ 34 Abs. 8 S. 3 ff. 
BDSG). 


Die Auskunft muss nicht durch die verantwortliche Stelle selbst erfolgen. Sie 
kann auch einen Auftragsdatenverarbeiter anweisen, die Auskunft in ihrem 
Namen und Auftrag zu erteilen. ! 


Das Verfahren zur Auskunftserteilung ist in $ 34 Abs. 1 S. 2 BDSG nur 
rudimentär geregelt. Damit besteht für die verantwortliche Stelle die nötige Fle- 
xibilität das Auskunftsverfahren an die eigenen Geschäftsprozesse anzupassen. 
Eine elektronische Plattform, auf der permanent eine aktuelle Auskunft erhalten 
werden kann, ist nicht vorgeschrieben. Für eine Schaffung einer permanent 
verfügbaren Online-Auskunft haben sich jedoch schon in den Anfangstagen 
der Internetwirtschaft Stimmen erhoben.” 


Seit der Novellierung des BDSG im Jahr 2009 ermöglicht $ 34 Abs. 6 BDSG die 
Auskunft in Textform? nach $ 126b BGB (vormals: Schriftform), soweit nicht 
aufgrund besonderer Umstände eine andere Form angemessen ist. Dadurch ist 
grundsätzlich die Wahl einer elektronischen Beauskunftung gewährleistet.* 
Erforderlich ist jedoch die Sicherstellung der dauerhaften Wiedergabe. Die reine 
Bereitstellung der Auskunft auf einer Webseite ist deshalb nicht ausreichend. ° 


1 Gola/Schomerus, BDSG 2015, § 34 Rn. 13. 

2 Roßnagel/Pfitzmann/Garstka 2001, 174 f. 

3 Abweichend obliegt die Form der Auskunft öffentlicher Stellen nach § 19 Abs. 1 S. 4 BDSG 
pflichtgemäßem Ermessen. 

4 Nach § 13 Abs. 7 S. 2 TMG ist auf Verlangen des Nutzers immer die elektronische Form zu 
wählen. 

5 KG Berlin, CR 2006, 680; Meents/Hinzpeter in: Taeger/Gabel, BDSG 2013, BDSG § 34 Rn. 41; 
a. A. für den Anwendungsbereich des TMG Moos in: Taeger/Gabel, BDSG 2013, TMG § 13 Rn. 
59. 
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3.5 Art und Weise der Auskunftserteilung 


Es liegt außerhalb der Einflusssphäre des Auskunftsverpflichteten, ob der 
Betroffenen die Auskunft herunterlädt und abspeichert oder nicht.! 


Sobald jedoch eine integritätssichernde Download-Möglichkeit zur Verfügung 
gestellt wird, wird dem Empfänger die dauerhafte Wiedergabe ermöglicht. 
Entscheidend ist, ob die Auskunft als Zugegangen zu werten ist. Es kann nicht 
darauf abgestellt werden, dass der Auskunftsverpflichtete keinerlei Einfluss 
auf die Akzeptanz des Download-Vorschlags hat. Wird die Webseite als 
regelmäßiges Kommunikationsmedium zwischen den Beteiligten genutzt oder 
wird der Download in direktem Zusammenhang mit einem elektronischen 
Auskunftsersuchen auf der Webseite angeboten, kann davon ausgegangen 
werden, dass schon ein passwortgeschützter Bereich auf der Webseite als 
Herrschaftsbereich des Auskunftsersuchenden zu werten ist.” 


Gibt es keinen entsprechenden Bereich, wäre ein weiterer möglicher Lösungs- 
weg zumindest die Initialisierung des Downloads der aktuellen Auskunft vor 
der Nutzung einer interaktiven Plattform zu erzwingen. Eine solche Maßnahme 
ist jedoch weder im Interesse des Betroffenen noch des Auskunftsverpflich- 
teten. Die Textform soll den Betroffenen schützen und ihn nicht in der Art 
der Wahrnehmung seiner Rechte einschränken. Deshalb scheint eine weite 
Auslegung des Begriffs der besonderen Umstände aus $ 34 Abs. 6 BDSG 
angebracht. Ist es den Umständen nach im Interesse aller Beteiligten von der 
Erzwingung der Textform abzusehen, ist dementsprechend zu verfahren. Ein 
normaler Download-Link ist deshalb ausreichend. 


Die DSGVO erlaubt bzw. fordert zukünftig eine elektronische Antwort, soweit 
die Anfrage elektronische gestellt wurde (Art. 12 Abs. 3 S. 4 DSGVO). Insofern 
werden die Anforderungen an die verantwortliche Stelle eher entschärft. 


Besondere Vorsicht bei der Wahl der Form ist bei besonders sensiblen perso- 
nenbezogenen Daten (z. B. medizinischen Daten) angebracht. Eine mündliche 
Auskunft erlaubt es dem Betroffenen eher, seine personenbezogenen Daten 


! Dix in: Simitis, BDSG 2014, $ 34 Rn. 49. 
? Robrecht 2015, 20 hält bereits die Zusendung eines zugangsgeschützten Links für ausreichend. 
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vor Dritten zu verheimlichen. Besteht diese Gefahr nicht, sind besondere 
Vorsichtsmaßnahmen bei der Übermittlung der besonders sensiblen Daten 
zu treffen. Eine Übermittlung im verschlossenen Umschlag oder in digital 
verschlüsselter Form erhöht die Vertraulichkeit und ist für solche Datenarten 
unumgänglich. 


Je nach Charakter der Daten ist namentlich für medizinische Daten eine 
interaktive Einsichtsgewährung vorzuziehen.'! Medizinische Informationen 
sind erklärungsbedürftig und verlangen eine Vermittlung durch fachkundiges 
Personal. Eine rein faktenbasierte Auskunft kann zu Fehlschlüssen und einer 
Gefährdung von Patient und Behandlungserfolg führen.” 


Die Art der Auskunft ist an den gesundheitlichen Bedürfnissen des Patienten 
auszurichten. Es ist die Ansprache derjenigen Sinne erforderlich, die noch am 
besten funktionieren (Sehen, Hören, Fiihlen).? 


3.6 Speicherfrist 


Eine generelle Festlegung der erforderlichen Speicherfristen fiir die vom 
Auskunftsanspruch umfassten Informationen ist durch den Gesetzgeber bisher 
nicht erfolgt. Es obliegt deshalb der verantwortlichen Stelle eine angemessene 
Frist festzulegen.* Eine Orientierung bietet die Speicherfrist der Basisdaten. 
Die Speicherfrist der Basisdaten ergibt sich aus den gewählten Lischfristen.> 
Nach ErwGr 39 DSGVO ist die verantwortliche Stelle künftig angehalten, 
solche Löschfristen oder regelmäßige Überprüfungen für personenbezogene 
Daten vorzusehen. Die Löschfristen sind gemäß Art. 25 Abs. 2 S. 2 DSGVO 
automatisiert durchzusetzen oder organisatorisch zu gewährleisten. 


! Scheiwe 1998, 319. 

2 BGH, NIW 1983, 328 (329 f.). 

3 BVerfG, NJW 2005, 1103 (1104). 

4 Dix in: Simitis, BDSG 2014, $ 34 Rn. 23. 

5 Für solche Löschfristen wurde die Norm DIN 66398:2016-05 „Leitlinie zur Entwicklung eines 
Löschkonzepts mit Ableitung von Löschfristen für personenbezogene Daten“ entwickelt, die 
sich an den durch Hammer, DuD 2011, 890 dargelegten Verfahrensweisen orientiert. 
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3.6 Speicherfrist 


Werden Daten länger gespeichert, als von einer gesetzlichen Aufbewahrungsfrist 
vorgeschrieben, sind sie für den längeren Zeitraum zu beauskunften.! 


Für einzelne Sonderfälle finden sich Anhaltspunkte für die Speicherfrist im Ge- 
setz. Bei der Übermittlung listenmäßiger personenbezogener Daten zum Zwecke 
der Werbung gemäß § 28 Abs. 3 S. 4 BDSG gilt nach § 34 Abs. la BDSG eine 
Speicherfrist für Herkunft und Empfänger von zwei Jahren nach der Übermitt- 
lung. Scoring-Daten unterliegen einer Speicherfrist von sechs Monaten gemäß 
§ 34 Abs. 2S. 1 Nr. 1 BDSG. Wer personenbezogene Daten zum Zweck der 
Übermittlung erhebt, speichert oder verändert, hat nach § 34 Abs. 4 S. 1 Nr. 1 
BDSG die innerhalb der letzten zwölf Monate vor Zugang des Auskunftsver- 
langens übermittelten Wahrscheinlichkeitswerte (Scores) und deren Empfänger 
zu beauskunften und dementsprechend auch zu speichern. Eine Vereinbarkeit 
dieser einfach-gesetzlichen Regelungen mit der Rechtsprechung des EuGH, 
insbesondere bei längerer Speicherung der Basisdaten, ist zweifelhaft.” 


Das Recht auf Auskunft gilt auch für die Vergangenheit und die gewählte Spei- 
cherfrist muss die Ausübung dieses Rechts wirksam ermöglichen.? Zwischen 
den Rechten des Betroffenen und der Belastung für die verantwortliche Stelle 
muss ein angemessener Ausgleich stattfinden.* 


Wenn sich die Speicherfrist der für die Auskunft relevanten Informationen 
allein an der entsprechenden Frist der Basisdaten orientiert, wären Datenpfade 
nach Löschung der Basisdaten nicht mehr reproduzierbar. Damit wird dem 
Betroffenen die Möglichkeit genommen, Schritt für Schritt nachzuvollziehen, 
welchen Weg seine personenbezogenen Daten genommen haben und wer sie 
aktuell vorhält. Dementsprechend darf die Angabe der Empfänger erst dann ge- 
löscht werden, wenn auch die Basisdaten bei Empfängern und Folgeempfängern 
gelöscht sind. 


! BGH, BeckRS 2001, 30158545. 
2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 32. 
3 EuGH, EuZW 2009, 546 (549). 
4 EuGH, EuZW 2009, 546 (550). 
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Für die solcherart gespeicherten Daten gilt eine besonders strenge Zweckbin- 
dung an die Auskunftserteilung. Für alle anderen Zwecke sind sie zu sperren 
(§ 34 Abs. 5 BDSG). 


3.7 Umfang des Rechts auf Auskunft 


Die grundlegenden Regelungen zum Recht auf Auskunft sind für öffentliche 
und nicht-öffentliche Stellen identisch. $ 19 Abs. 1 S. 1 sowie $ 34 Abs. 1 
S. 1 BDSG entsprechen sich und sind in Teilen sogar wortgleich. Einzig 
das Abstellen auf den Antrag als Willenserklärung ist eine Besonderheit des 
öffentlichen Rechts. 


Die vorgenannten Rechtsnormen geben den Umfang des Auskunftsanspruchs 
vor. Der Auskunftsanspruch umfasst nach $ 19 Abs. 1S. 1 bzw. $ 34 Abs. 1 
S. 1 BDSG! 


e die gespeicherten personenbezogenen Daten, 
e ihre Herkunft, 

e die Empfänger der Daten und 

e den Zweck der Speicherung. 


Art. 15 Abs. 1 DSGVO ergänzt die Auskunft zukünftig um die geplante 
Speicherdauer, die Kategorien der personenbezogenen Daten, alle Verarbei- 
tungszwecke sowie um eine Unterrichtung über die Rechte des Betroffenen 
und die Garantien bei Drittlandübermittlungen.? 


1 § 83 SGB X unterscheidet sich inhaltlich nicht wesentlich von den Vorgaben des BDSG; § 13 
TMG und $ 93 TKG verweisen jeweils auf $ 34 BDSG. 

? Hohmann in: Roßnagel 2017, $ 3 Rn. 135. Eine tabellarische Übersicht zum Vergleich des 
inhaltlichen Umfangs des Auskunftsrechts in DSGVO und BDSG findet sich in Laue/Nink/Kremer 
2016, $ 4 Rn. 24. Ob durch Art. 15 Abs. 3 S. 1 DSGVO ein eigenständiges Recht auf Kopie 
konstituiert wird oder ob dieses Recht in Art. 15 Abs. 1 aufgeht, hat für Umfang und Reichweite 
des Rechts auf Auskunft als Ganzes keine Bedeutung. 
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Herkunft- und Empfangerangaben unterschiedlicher verantwortlicher Stellen 
ergänzen sich zu einer durchgängigen Speicher- und Verarbeitungshistorie 
eines jeden personenbezogenen Datums. Jeder Ubermittlung, ausgehend von 
der einen verantwortlichen Stelle, steht eine Erhebung bei einer anderen 
verantwortlichen Stelle gegenüber. ! 


3.7.1 Gespeicherte personenbezogene Daten 
Legaldefinition und Reichweite des Begriffs 


Anknüpfungspunkt des Schutzbereichs des Datenschutzrechts ist das perso- 
nenbezogene Datum.” Denn das Datenschutzrecht soll die Beeinträchtigung 
der Persönlichkeitsrechte des Einzelnen durch die Erhebung und Verwendung 
seiner personenbezogenen Daten verhindern.’ Ist der Umgang mit personenbe- 
zogenen Daten nicht transparent, ist es dem betroffenen Bürger nicht möglich, 
selbst über den Umgang zu verfügen oder ihn zu beeinflussen. 


Nach der Legaldefinition des $ 3 Abs. 1 BDSG sind personenbezogene Daten alle 
„Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten 
oder bestimmbaren natürlichen Person [...].““ Die Person ist bestimmt, wenn 
sich der Bezug zwischen der Person und den Einzelangaben direkt ergibt und 
eindeutig feststeht.* Der Bezug ergibt sich direkt, wenn die Einzelangabe durch 
die auskunftspflichtige Stelle mit einem eindeutigen Identifikator verknüpft 
ist.> 


Ein Identifikator kann ein expliziter Identifikator oder ein aus mehreren Attri- 
buten zusammengesetzter Quasi-Identifikator sein. Ein expliziter Identifikator 


! Übermittlung und Erhebung bedürfen jeweils einer eigenen Rechtsgrundlage — BVerfGE 130, 
151 (184). 

? Bei personenbezogenen Daten handelt es sich eigentlich um Informationen; vgl. Spiecker genannt 
Döhmann 2016, 137. 

3 BVefGE 65, 1. 

4 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 22. 

5 Art. 4 Nr. 1 DSGVO spricht statt von „Bestimmbarkeit‘ von ,,Identifizierbarkeit, meint jedoch 
dasselbe. 
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ist selbst ein personenbezogenes Datum. Beispiele sind Kundennummern, So- 
zialversicherungsnummern, oder Ausweisnummern. Solche Nummern werden 
im Regelfall selbst erst dadurch zum Identifikator, dass sie, beispielsweise 
in einer Kundendatenbank, auf Quasi-Identifikatoren (Name, Geburtsdatum, 
Geburtsort, Adresse, ...) verweisen. Ihr Personenbezug entsteht also durch den 
Kontext.! Einzig charakteristische biometrische Merkmale und genetische 
Marker sind originäre explizite Identifikatoren.” 


Die Bestimmbarkeit einer natürlichen Person ergibt sich im Falle des Aus- 
kunftsanspruchs aus der Möglichkeit der Zuordnung der Daten zum Betroffenen 
durch die verantwortliche Stelle. Der Personenbezug ist relativ.” Es sind die 
rechtlichen und tatsächlichen Mittel zu berücksichtigen, die von der verant- 
wortlichen Stelle eingesetzt werden können.* Dabei müssen nicht alle zur 
Identifizierung des Betroffenen notwendigen Informationen in der Hand der 
verantwortlichen Stelle liegen. Es muss ihr nur möglich sein, sie in rechtlich 
zulässiger Weise zu einem späteren Zeitpunkt zu erlangen.” 


Nicht jedes potentiell zuordenbare Datum ist zum Zwecke der Auskunft 
dem Betroffenen zuzuordnen. Es ist nicht im Sinne des Datenschutzes, dort 
zwanghaft Bezüge zu natürlichen Personen herzustellen, wo sie für eine 
verantwortliche Stelle nicht mit vertretbarem Aufwand herstellbar sind und 
ohne das Auskunftsverlangen auch nie hergestellt würden. Auf der anderen 
Seite umfasst der Auskunftsanspruch auch Daten, die gegenwärtig noch keinen 
Personenbezug aufweisen, deren Personenbezug aber im Rahmen bestimmter 
Prozesse im Regelfall hergestellt wird. Entsprechende Regelungen finden 
sich insbesondere für das Scoring (§ 34 Abs. 2 S. 2 Nr. 1 BDSG) und für 
die geschäftsmäßige Speicherung personenbezogener Daten zur Übermittlung 
(Auskunfteien, Adresshandel — § 34 Abs. 3 S. 2 Nr. 1 BDSG). 


! Dammann in: Simitis, BDSG 2014, § 3 Rn. 61. 

2 Dammann in: Simitis, BDSG 2014, § 3 Rn. 73. 

3 Gola/Schomerus, BDSG 2015, $ 3 Rn. 10; Dammann in: Simitis, BDSG 2014, $ 3 Rn. 32 
m. w.N. in Fn. 109; a. A. z.B. Weichert, DuD 2007, 113 (115); Pahlen-Brandt, DuD 2008, 34 
(37 ££.). 

4 ErwGr 26 DSRL; ErwGr 26 DSGVO; EuGH, EuZW 2016, 909. 

5 EuGH, EuZW 2016, 909 (911). 

6 Gola/Schomerus, BDSG 2015, $ 34 Rn. 8b. 
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Persönliche und sachliche Verhältnisse eines Betroffenen sind in Summe 
alle Angaben zu einer Person, unabhängig von ihrer jeweiligen Semantik 
(Bedeutung), Sigmatik (Hinweisfunktion und Zweckbezug) oder Pragmatik 
(Verwendung und Kontext).! Seinen datenschutzrelevanten Gehalt bekommt 
das Datum schon durch seinen Bezug zur Person. Die Relevanz ergibt sich 
aus dem Zusammenhang. Kein Datum kann abstrakt als belanglos qualifiziert 
werden.” Sachliche Verhältnisse, die einer Person zugeordnet werden können, 
aber keine persönlichkeitsrechtliche Relevanz in sich tragen, unterliegen nicht 
dem Datenschutzrecht.? Nach der „3-Elemente-Theorie“ ist eine Relevanz 
immer dann anzunehmen, wenn das Datum ein Inhaltselement (Information 
über den Betroffenen), ein Ergebniselement (Auswirkung auf den Betroffenen) 
oder ein Zweckelement (Vorhaben, den Betroffenen auf Grundlage des Datums 
zu beurteilen) in sich trägt.* 


Eine abstrakte Entscheidung, ob eine Angabe ein personenbezogenes Datum 
oder ein Teil eines Datums ist, oder ob mehrere Daten vorliegen, ist nicht 
möglich.” Beispielsweise kann man einen Namen als Ganzes als personen- 
bezogenes Datum auffassen. Man kann jedoch auch seine Bestandteile Titel, 
Familienname und Vornamen als kleinste Einheit heranziehen. Es ist sogar 
noch möglich in einzelne Vornamen oder Namensbestandteile zu differen- 
zieren. Entscheidend für die Granularität personenbezogener Daten sind der 
Verwendungszusammenhang und die allgemeine Verkehrsanschauung.® Die 
technische Realisierung kann nur mittelbar als Ergebnis einer beim Entwurf 
einer Datenverarbeitung erfolgten Wertung herangezogen werden. Von der 
Festlegung hängt ab, ob eine Ergänzung im Datenbestand eine Änderung eines 
personenbezogenen Datums oder eine zusätzliche Speicherung ist.’ 


l Dammann in: Simitis, BDSG 2014, $ 3 Rn. 6. 

2 BVerfGE 65, 1 (45). 

3 Weichert, VuR 2009, 323 (325). 

* Artikel-29-Datenschutzgruppe 2007, 11 ff. 

5 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 133. 
6 Dammann in: Simitis, BDSG 2014, § 3 Rn. 133. 
7 Dammann in: Simitis, BDSG 2014, § 3 Rn. 132. 
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Einzelne Arten personenbezogener Daten 


Im Folgenden werden personenbezogene Daten detailliert beleuchtet, die für 
das Recht auf Auskunft von besonderer Wichtigkeit sind. 


Von Belang ist die Verortung eines Datums. Der Ort der Speicherung (IT- 
System, Akte, Datenbank,...) und Verarbeitung i.e.S. (Prozess) hat selbst 
Aussagekraft über die betroffene Person.! Ist ein Datum im IT-System für 
die Inkassoabwicklung gespeichert, hat bereits diese Information Einfluss auf 
die Bonität. Befindet sich der Name einer natürlichen Person in einer Liste 
wertvoller Stammkunden, hat auch dieser Zusammenhang Aussagekraft, ohne 
dass es einer weiteren Kennzeichnung bedarf. Besonders zu beachten sind 
auch Dateinamen. Sie weisen dem personenbezogenen Datum Attribute zu 
(Erstellungszeitpunkt, Kategorie, o.ä.) und dienen als Selektionskriterien.? 
Ähnliche Schlussfolgerungen lassen sich auch aus der Struktur der Datenablage 
ziehen. Analog zu $ 6a BDSG ist deshalb auch der logische Aufbau der 
gespeicherten personenbezogenen Daten Teil des Auskunftsanspruchs. ° 


Der Zeitpunkt einer Erhebung, Verarbeitung und Nutzung personenbezogener 
Daten kann auch personenbezogenes Datum sein. Im Falle der Erhebung beim 
Betroffenen gibt er Auskunft über eine Interaktion zwischen Betroffenem und 
verantwortlicher Stelle. So kann der Zeitpunkt einer Erhebung beispielsweise 
einen Kaufzeitpunkt für ein bestimmtes Produkt oder den Zugriffszeitpunkt auf 
eine Webseite widerspiegeln. Aus solchen Informationen lassen sich umfang- 
reiche Persönlichkeitsprofile bilden. Auch der Zeitpunkt einer Kommunikation 
mit Dritten (Erhebung und Übermittlung) ist für den Betroffenen von Relevanz. 
Wann wer was über ihn weiß beeinflusst direkt seine Handlungsmöglichkeiten. 


Schwieriger ist der Zeitpunkt der internen Verarbeitung und der Nutzung zu 
fassen. Da mit personenbezogenen Daten des Betroffenen umgegangen wird, 


! Betrifft auch den geografischen Ort, z.B. beim Cloud Computing, so Dix in: Simitis, BDSG 
2014, $ 34 Rn. 23. 

2 HessVGH, RDV 1991, 187 (188); Dix in: Simitis, BDSG 2014, § 34 Rn. 17; Gola/Schomerus, 
BDSG 2015, § 34 Rn. 9 und Mallmann in: Simitis, BDSG 2014, § 19 Rn. 21. 

3 Meents/Hinzpeter in: Taeger/Gabel, BDSG 2013, BDSG § 34 Rn. 17. 
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ergibt sich zwar zwangsläufig ein Personenbezug, fraglich ist jedoch die Aus- 
kunftsrelevanz, vor allem im Vergleich mit den Interessen der verantwortlichen 
Stelle. Genaue Verarbeitungszeitpunkte legen Betriebsgeheimnisse offen und 
setzten bei nicht-vollautomatisierter Verarbeitung auBerdem die Mitarbeiter der 
verantwortlichen Stelle unter einen Uberwachungsdruck. Wie diese Rechtsgiiter 
abzuwägen sind, kann nur im Einzelfall beantwortet werden. ! 


Innerhalb einer Kommunikationsbeziehung sind Herkunft? und Empfänger? 
nicht nur auskunftspflichtige Informationen, weil sie explizit aufgeführt sind, 
sondern auch, weil es sich bei diesen Angaben selbst um personenbezogene 
Daten des Betroffenen handelt.* Dadurch, dass Sender und Empfänger jeweils 
personenbezogene Daten des Betroffenen verarbeiten, stehen sie in einer 
Beziehung zu diesem. Sind Herkunft und Empfänger natürliche Personen, 
ergibt sich ein doppelter Personenbezug? und dadurch das Erfordernis einer 
Abwägung zwischen den Rechten des einen Betroffenen auf Auskunft und den 
Rechten des anderen Betroffenen auf das Datengeheimnis. 


Auch andere Kommunikationskonstellationen und Sozialbeziehungen zwischen 
natürlichen Personen führen im Regelfall zu einem doppelten Personenbezug. 
Gleiches gilt für Bilddaten (Fotografien, Videoaufnahmen): Sind auf ihnen 
mehrere Personen abgebildet, entsteht zu jeder einzelnen Person ein Perso- 
nenbezug. Ein doppelter oder mehrfacher Personenbezug gespeicherter Daten 
führt zu einem Auskunftsanspruch jeder betroffenen Person. ® 


Gesperrte personenbezogene Daten sind weiterhin gespeicherte Daten und 
unterliegen damit der Auskunftspflicht.” Häufig handelt es sich bei gesperrten 
Daten jedoch um Daten, die gesetzlichen, satzungsmäßigen oder vertraglichen 


! Mehr dazu in Abschnitt 3.8. 

2 Mehr dazu in Abschnitt 3.7.3. 

3 Mehr dazu in Abschnitt 3.7.2. 

4 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 47; Dix in: Simitis, BDSG 2014, $ 34 Rn. 22; a. A. 
BGH, NJW 1981, 1738 (1739) für das BDSG 1977. 

5 Dammann in: Simitis, BDSG 2014, § 3 Rn. 43, 45. 

6 Zur Abwägungen im Einzelfall siehe Abschnitt 3.8. 

7 Dix in: Simitis, BDSG 2014, $ 34 Rn. 19. 
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Aufbewahrungsvorschriften unterliegen. Solche Daten sind nach § 34 Abs. 7 
i. V.m. § 33 Abs. 2 S. 1 Nr. 2 nicht verpflichtend zu beauskunften. ! 


Der Auskunftsanspruch umfasst nicht nur die gespeicherten Daten, sondern 
auch übermittelte Daten.” Dies erfordert eine durchgängige und feingranulare 
Historie von Ubermittlungen mit Bezug auf gespeicherte Daten.* Eine eigene 
Speicherung der Inhalte übermittelter Daten für sonst bereits gelöschte Daten 
ist jedoch unverhältnismäßig. 


Für medizinische Daten hat die Rechtsprechung weitergehende Vorgaben 
gemacht. Neben dem datenschutzrechtlichen Auskunftsrecht wurde ein zi- 
vilrechtliches Einsichtsrecht entwickelt, welches auch für nicht in Dateien 
abgelegte Aufzeichnungen gilt.* Diese ergänzenden Rechte liegen auch darin 
begründet, dass medizinische Daten besonders sensible Daten des Betroffenen 
im Sinne des $ 3 Abs. 9 BDSG sind. Speziell vor Abschluss der Behandlung 
besteht ein gesteigertes Interesse des Betroffenen, die weitere Verwendung 
seiner personenbezogenen Daten zu kontrollieren und ihren Charakter zu ana- 
lysieren.> Auf der anderen Seite sind berechtigte Interessen des behandelnden 
Arztes zu berücksichtigen (siehe Abschnitt 3.8.2). 


Aufgezeichnete Daten, die den bisherigen Umgang mit einem personenbezoge- 
nen Datum beschreiben (Data-Provenance), sind auch selbst personenbezogene 
Daten. Eine Auskunft nach $ 34 BDSG ist keine Übermittlung, da sie nicht 
gegenüber einem Dritten erfolgt. Als Nutzung personenbezogener Daten ist sie 
dennoch selbst zu beauskunften. So hat der Betroffene auch die Möglichkeit 
zu überprüfen, ob sich unberechtigte Dritte im Wege der Auskunft Zugang zu 
seinen personenbezogenen Daten verschafft haben. 


Dix in: Simitis, BDSG 2014, $ 34 Rn. 57. 
Dix in: Simitis, BDSG 2014, $ 34 Rn. 23. 

3 Sydow, NVwZ 2013, 467 (470). 

4 BGH, NJW 1983, 328; BGH, NJW 1983, 330. 
5 BGH, NJW 1985, 674 (675). 


1 
2 
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3.7.2 Empfänger 


Gemäß $ 3 Abs. 8 S. 1 BDSG ist Empfänger „jede Person oder Stelle, die Daten 
erhält.“ Mit Personen sind sowohl natürliche als auch juristische Personen 
gemeint. Der Betroffene selbst kann auch Empfänger sein. Der Begriff der 
Stelle ist komplexer und führt zu einem differenzierten Empfängerbegriff. 


Stelle 


Der Stellenbegriff des Datenschutzrechtes geht über den verwaltungsrechtlichen 
Stellenbegriff nach $ 1 Abs. 4 VwVfG hinaus. Er bezeichnet auch nicht- 
öffentliche, private Gebilde. Der Stellenbegriff kann sowohl funktional als auch 
organisatorisch interpretiert werden. ! 


Der funktionale Stellenbegriff ist zweckbestimmt. Er macht den Übergang eines 
Datums von einer Stelle auf eine andere am Wechsel der Aufgabe bezüglich 
der Verarbeitung und Nutzung der Daten fest. Ein IT-System oder eine IT- 
Applikation ist dann einer dezidiert anderen Stelle zuzuordnen, wenn ihm eine 
inhärent andere Rolle und Funktionalität in der Datenverarbeitung zukommt. 


Der organisatorische Stellenbegriff ist von der juristischen Person bzw. dem 
Rechtsträger verschieden.” Er orientiert sich an der aufbauorganisatorischen 
Struktur einer Organisation. In hierarchischen Organisationen geht ein Stel- 
lenwechsel meist mit einer Änderung der Weisungsbefugnis, zumindest auf 
der niedrigsten Verantwortungsebene, einher. Filialen oder Betriebe sind keine 
Stellen.” Die räumliche Struktur einer Organisation ist für den organisatori- 
schen Stellenbegriff unerheblich. Eine beschäftigte natürliche Person ist, soweit 
sie in ihrer dienstlichen Funktion handelt, dem Arbeitgeber bzw. Dienstherren 
zuzuordnen und damit keine eigene Stelle.* 


! Dammann in: Simitis, BDSG 2014, § 2 Rn. 15. 

2 Dammann in: Simitis, BDSG 2014, § 3 Rn. 231. 
3 Dammann in: Simitis, BDSG 2014, § 3 Rn. 233. 
4 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 234. 
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Indem der Gesetzgeber die Zweckbindung liickenlos gewihrleistet! folgt er im 
Ergebnis dort dem funktionalen Stellenbegriff,” wo umfassende Nutzungsre- 
gelungen fehlen.* 


Zusammenfassend kann festgestellt werden, dass der Empfängerbegriff alle 
Organisationseinheiten,* denen die Daten zur Nutzung zur Verfügung gestellt 
werden,” und alle dem Zweck nach vom Sender verschiedene IT-Systeme und 
IT-Applikationen innerhalb der verantwortlichen Stelle umfasst.° „Offenzule- 
gen ist somit auch der interne Datenfluss und zwar auch bei nicht-automatisierter 
Verarbeitung.“’ 


Die DSGVO führt eine rechtsdefinitorische Klärung des Empfängerbegriffs 
herbei. Die in den obigen Ausführungen zum BDSG vertretene Interpretation 
wird bestätigt. In Art. 4 Nr. 9 DSGVO ist festgehalten, dass jede Person 
oder Stelle Empfänger ist, der gegenüber personenbezogene Daten offengelegt 
werden, „unabhängig davon, ob es sich bei ihr um einen Dritten handelt, oder 
nicht“.® Eine in der Auslegung offene Frage ist, ob alle Organisationseinheiten 
innerhalb eines Unternehmens Empfänger sind oder ob eine gewisse Eigen- 
ständigkeit verlangt wird.” Im Ergebnis sollte die Eigenständigkeitserwägung 
zu den selben Resultaten kommen, wie die organisatorische und funktionale 
Interpretation des Stellenbegriffs. 


1 84 Abs. 1 BDSG i.V.m § 14 Abs. 1 für öffentliche Stellen bzw. $ 28 Abs. 1 S. 2 für eigene 
Geschäftszwecke nicht-6ffentlicher Stellen. 

2 Dammann in: Simitis, BDSG 2014, $ 2 Rn. 16. 

3 Dammann in: Simitis, BDSG 2014, $2 Rn. 18. 

4 Unabhängig davon, ob sie Dritte sind oder nicht. — EuGH, C-553/07, ECLI:EU:C:2009:293, Rn. 
11. 

5 Gola/Schomerus, BDSG 2015, $ 3 Rn. 51. 

6 Weitere Ausführungen zur verantwortlichen Stelle finden sich in Abschnitt 3.7.4. 

7 Gola/Schomerus, BDSG 2015, § 34 Rn. 2. 

8 Schreiber in: Plath, BDSG/DSGVO 2016, Art. 4 DSGVO, Rn. 29 geht im Widerspruch zu Art. 
4 Nr. 10 DSGVO davon aus, dass Auftragsverarbeiter Dritte sind und begrenzt irrigerweise den 
Empfängerbegriff auf solche Stellen, die nicht Teil der verantwortlichen Stelle sind. 

9 Ernst in: Paal/Pauly, DSGVO 2017, Art. 4 DSGVO, Rn. 57. 
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Dritte 


Nach § 3 Abs. 8 S. 2 BDSG ,,ist jede Person oder Stelle auBerhalb der 
verantwortlichen Stelle“ Dritter.! Ausgenommen sind der Betroffene (§ 3 Abs. 8 
S. 3 Alt. 1 BDSG) und der Auftragsdatenverarbeiter (§ 3 Abs. 8 S. 3 Alt. 2 
BDSG). Beispielhaft sind zwei Behörden, zwei Ämter oder zwei natürliche 
bzw. juristische Personen Dritte füreinander. Organe einer verantwortlichen 
Stelle sind keine Dritten.? 


Eine organisationsinterne Weitergabe von personenbezogenen Daten zwecks 
Arbeitsteilung ist keine Ubermittlung, da sie innerhalb der verantwortlichen 
Stelle stattfindet.” Handelt es sich bei dem Empfänger personenbezogener 
Daten um einen Dritten, ist der Tatbestand der Ubermittlung erfüllt. Die 
Weitergabe personenbezogener Daten an einen Empfänger, der nicht Dritter 
ist, ist als Nutzung zu klassifizieren.* Die rechtlichen Voraussetzungen für eine 
Übermittlung sind strenger als für eine Nutzung. Beide unterliegen jedoch der 
Zweckbindung. Für den nachgelagerten Auskunftsanspruch ist es unerheblich, 
ob der Empfänger Dritter ist oder nicht. Sowohl die einfache Weitergabe 
als auch die Übermittlung personenbezogener Daten sind zu beauskunften. 
Allerdings ist das Erfordernis einer Auskunft über Empfänger, die Dritte sind, 
zu personenbezogenen Daten, die aus Öffentlichen Quellen entnommen wurden, 
fraglich.’ 


Während die Auskunft bezüglich der Nutzung und Weitergabe personenbe- 
zogener Daten durch die verantwortliche Stelle abschließend erfolgen kann, 
eröffnet sich durch die Auskunft über eine Übermittlung an Dritte ein neuer 
Auskunftsbedarf, der an den Empfänger zu richten ist. Ein Empfänger perso- 
nenbezogener Daten, der Dritter ist, ist wiederum selbst verantwortliche Stelle 
für die Erhebung, Verarbeitung und Nutzung personenbezogener Daten. Die 
Relevanz einer Auskunft über Übermittlungen ist für den Betroffenen also 


' In Zukunft sinngemäß gleich: Art. 4 Nr. 10 DSGVO. 

2 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 238 ff. 

3 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 234. 

4 Gola/Schomerus, BDSG 2015, § 3 Rn. 49; Dammann in: Simitis, BDSG 2011, § 3 Rn. 193 
5 AG Leipzig, BeckRS 2014, 14721. 
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ungleich höher. Die in der Auskunft gemachten Angaben müssen eine weitere 
Inanspruchnahme des Auskunftsrechts beim Empfänger ermöglichen. ! Es muss 
deshalb nicht nur eine Adresse oder Kontaktmöglichkeit angegeben werden,” 
sondern es müssen auch all die Informationen, die eine Übermittlung für den 
Empfänger referenzierbar machen (z. B. Zeitpunkt, Inhalt der Übermittlung, 
Gegenstelle beim Empfänger), enthalten sein.” 


Die Auskunft legt auf der anderen Seite die Geschäftsbeziehungen der verant- 
wortlichen Stelle offen und berührt damit im Besonderen Geschäftsgeheimnisse 
der verantwortlichen Stelle. 


Kategorien von Empfängern 


Die Beauskunftung gemäß § 34 Abs. 1 S. Nr. 2 Alt. 2 von Kategorien von 
Empfängern statt der Empfänger selbst erhält ihren Sinn in der Bevorzugung 
der Weitergabe von personenbezogenen Daten an gleichartige Empfänger zu 
gleichen Zwecken. Dahinter steht die Annahme, dass diese gleichartige Wei- 
tergabe auch eine gleichartige, geringfügige Gefährdung mit sich bringt. Damit 
ist die Zusammenfassung von Empfängern zu Kategorien von Empfängern 
dann ausgeschlossen, wenn der Betroffene ein Interesse daran hat, die unter- 
schiedlichen Empfänger auseinanderhalten zu können. Dies ist immer dann der 
Fall, wenn besonders sensible oder nicht-standardisierte Daten weitergegeben 
werden oder es zulässig ist beziehungsweise damit gerechnet werden muss, dass 
der Empfänger die Daten selbst weitergibt. Es dürfen also nur Datensenken 
kategorisiert werden. 


In Summa erstreckt sich dieses Privileg im Regelfall auf die listenmäßige 
Weitergabe personenbezogener Daten (§ 28 Abs. 3 S. 2 BDSG) und Daten, 
die zur Einsicht bereitgehalten werden ($ 3 Abs. 4 Nr. 3 b) Alt. 1 BDSG). Der 
Gesetzgeber hat sich indes anders entschieden. Die listenmäßige Übermittlung 


1 Gebot des effektiven Rechtsschutzes, BVerfGE 65, 1 (70). 
2 Für das Scoring festgelegt in § 34 Abs. 4 S. 1 Nr. 1 BDSG. 
3 Für die Herkunft von Score-Daten entsprechend § 34 Abs. 2 S. 4 BDSG. 
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unterliegt einer Speicherpflicht des konkreten Empfängers (§ 28 Abs. 3 S. 4 
i. V.m. § 34 Abs. la BDSG). 


In der Literatur wird sogar vertreten, dass die verantwortliche Stelle gar kein 
Wahlrecht mehr hat, sondern immer Empfänger und ihre Kategorien mitteilen 
muss.! Ungeachtet dessen besteht bei der ex ante Angabe im Verfahrensver- 
zeichnis immer die freie Wahl.? 


3.7.3 Herkunft 


Im Gegensatz zu den Empfängern? besteht keine Pflicht zur Speicherung von 
Herkunftsangaben.* Es ist nur Auskunft über die Herkunftsangaben zu leisten, 
die sowieso gemeinsam mit den personenbezogenen Daten gespeichert sind. 


Es gibt jedoch eine Reihe von Sonderfällen, in denen die Speicherpflicht 
verschärft wird. Für Daten, die zum Zweck der Übermittlung gespeichert 
werden (insbesondere in Auskunfteien, Werbung und im Adresshandel) sind 
nach § 34 Abs. 1 S. 3 BDSG die verantwortlichen Stellen zur Speicherung der 
Herkunftsangaben verpflichtet. Werden personenbezogene Daten listenmäßig 
zum Zwecke der Werbung übermittelt, besteht nicht nur eine zweijährige Pflicht 
zur Speicherung der Herkunft (siehe Abschnitt 3.6), sondern nach $ 28 Abs. 3 
S. 4 BDSG müssen sogar Informationen über diejenige Stelle vorgehalten 
werden, die die Daten erstmalig erhoben hat. 


Allerdings kann eine Herkunftsangabe gemeinsam mit dem Zeitpunkt der 
Übermittlung eine nähere Angabe nach § 34 Abs. 1 S. 2 BDSG sein, die 
den Verlangenden als Betroffenen ausweist.” Der verantwortlichen Stelle sei 
es deshalb angeraten, Herkunftsangaben über einen ähnlichen Zeitraum zu 


! Meents/Hinzpeter in: Taeger/Gabel, BDSG 2013, BDSG $ 34 Rn. 21. 

2 Petri in: Simitis, BDSG 2014, § 4e Rn. 10. 

3 Dix in: Simitis, BDSG 2014, § 34 Rn. 23; Gola/Schomerus, BDSG 2015, § 19 Rn. 6; siehe auch 
Abschnitt 3.6. 

4 Gola/Schomerus, BDSG 2015, § 34 Rn. 10 u. § 19 Rn. 5 und zustimmend Dix in: Simitis, 
BDSG 2014, § 34 Rn. 22. 

5 Diesen Nachweis hält das LG München II (RDV 2006, 22) für erforderlich. 
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speichern wie Empfangerangaben. Nur dann kann sie gegen sie gerichteten 
Auskunftsanspriichen voll umfanglich gerecht werden. 


In letzter Konsequenz spielt die Verpflichtung zur Speicherung der Herkunfts- 
angaben nur zum Erhebungszeitpunkt eine eigenständige Rolle. Weitergaben 
zwischen Stellen innerhalb der verantwortlichen Stelle sind bereits durch die 
Speicherung des Empfängers auf der Herkunftsseite eindeutig identifiziert. 
Die Empfängerangaben der einen Seite sind die Herkunftsangaben der anderen 
Seite. Die verpflichtende Verfügbarkeit der Herkunftsinformationen, ausgehend 
vom Empfänger, ergibt sich aus der Globalität des Auskunftsanspruchs in 
Bezug auf das personenbezogene Datum innerhalb der verantwortlichen Stelle. 
Der Betroffene hat auch ein Recht darauf, verteilt abgelegte Informationszu- 
sammenhänge zu erfahren. 


Wird von der verantwortlichen Stelle behauptet, dass die Herkunft personenbe- 
zogener Daten in allgemein zugänglichen Quellen liegt, trägt sie im Rechtsstreit 
die Darlegungslast.! 


3.7.4 Verantwortliche Stelle 


Die verantwortliche Stelle (kurz: Verantwortlicher) ist diejenige Stelle, die 
Erhebung, Verarbeitung und Nutzung selbst durchführt oder durch andere im 
Auftrag durchführen lässt ($ 3 Abs. 7 BDSG).? 


Die Menge der verantwortlichen Stellen ist eine Teilmenge aller als Stellen 
bezeichneter Einheiten. Eine verantwortliche Stelle kann selbst wieder aus 
unterschiedlichen Funktions- und Organisationsgliedern bestehen, die für 
sich selbst auch Stellen, jedoch keine verantwortlichen Stellen sind. Die 
Ausführungen des $ 2 BDSG zu verantwortlichen Stellen verwenden allein den 
organisatorischen Stellenbegriff. Die verantwortliche Stelle ist somit immer 
organisatorisch und nicht funktional zu verstehen. 


1 AG Düsseldorf, Urteil vom 07.01.2009, MMR 2009, 872. 

2 Nach Art. 4 Nr. 7 DSGVO ist der Verantwortliche diejenige Stelle, die allein oder gemeinsam mit 
anderen über Zweck und Mittel der Erhebung, Verarbeitung und Nutzung personenbezogener 
Daten entscheidet. 
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Die Differenzierung in öffentliche und nicht-öffentliche Stellen, in Stellen 
des Bundes und der Länder ist für den auskunftsrechtlichen Stellenbegriff 
weitgehend unerheblich. Die Enumeration in $ 2 Abs. 4 S. 1 BDSG ist nicht 
abschließend, sondern exemplarisch zu verstehen. 


Jede natürliche Person ist verantwortliche Stelle, soweit sie für sich selbst 
handelt. $ 1 Abs. 2 Nr. 3 BDSG nimmt den Umgang mit personenbezoge- 
nen Daten zu ausschließlich persönlichen oder familiären Zwecken aus dem 
Geltungsbereich des BDSG aus und legt solchen Stellen keine Pflichten auf. 
Dennoch können diese privilegierten natürlichen Personen Dritte im Sinne des 
§ 3 Abs. 8 S. 2 BDSG sein. 


Jede juristische Person ist Stelle. „Auf die Rechtsform der nicht-öffentlichen 
Stelle kommt es [..] nicht an.“! Jede Personengesellschaft, jeder nicht- 
rechtsfähige Verein ist Stelle.” Empfangende Stellen, die eigene juristische 
Personen sind, aber dennoch der verantwortlichen Stelle zugeordnet werden, 
sind die Datenverarbeiter im Auftrag.’ 


Art 26 DSGVO führt die Figur des gemeinsam für die Verarbeitung Verant- 
wortlichen ein. Diese wurde bereits in Abschnitt 3.3 behandelt. 


3.7.5 Zweck 


Die Aufnahme des Zwecks in die zu beauskunftenden Daten in $ 19 Abs. 1 S. 1 
sowie § 34 Abs. 1 S. 1 BDSG folgt Art. 12 Lit. a erster Spiegelstrich DSRL. 


Ein Zweck ist ein auf ein Ziel hin ausgerichteter Grund für die Erhebung, 
Verarbeitung und Nutzung personenbezogener Daten. Aus dem Zweck folgt 
eine zieladäquate Handlung der verantwortlichen Stelle. 


l Dammann in: Simitis, BDSG 2014, $2 Rn. 118. 
2 Dammann in: Simitis, BDSG 2014, § 2 Rn. 121 f., 132 ff. 
3 Gola/Schomerus, BDSG 2015, § 34 Rn. 11. 
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3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


Die Angabe des Zwecks ist essentiell, da anhand dessen die Rechtmäßigkeit 
der Verwendung personenbezogener Daten bemessen wird.! Nur mit Hilfe des 
Zwecks kann der Betroffene bestimmen, ob er weitergehende Rechte hat. 


In § 28 Abs. 1 S. 2 BDSG wird der verantwortlichen Stelle die Festlegung des 
konkreten Zwecks? der Verarbeitung und Nutzung zum Zeitpunkt der Erhebung 
auferlegt. Aus der automatisierten Verarbeitung personenbezogener Daten folgt 
gemäß $ 4e S. 1 Nr. 4 BDSG sogar eine Pflicht zur noch frühzeitigeren 
Definition des jeweiligen Zwecks. Dieser a priori feststehende Zweck ist dem 
Betroffenen gegenüber zu beauskunften. 


Findet eine zulässige Zweckänderung für die Übermittlung und Nutzung der 
personenbezogenen Daten nach $ 28 Abs. 2 BDSG statt, muss auch dies im 
Rahmen der Auskunft sichtbar und nachvollziehbar werden.° Der Zweckbezug 
lässt sich insgesamt nur gewährleisten, wenn er auch nach einer Änderung und 
nach jedem Verarbeitungsschritt erkennbar bleibt.* Werden personenbezogene 
Daten zu mehreren unterschiedlichen Zwecken erhoben, verarbeitet oder 
genutzt, sind alle Zwecke zu beauskunften.> 


Da für den Betroffenen nicht ersichtlich ist, ob eine Dateibezeichnung einen 
Bezug zum festgelegten Zweck hat oder den vollständigen Zweck umfasst, kann 
ein Dateiname allein den Auskunftsanspruch nicht erfüllen.® Die Auskunft muss 
zumindest einen Hinweis enthalten, dass der Zweck im Dateinamen enthalten 
ist. Selbst in diesem Fall kann ein Dateiname nur den Zweck einer Speicherung, 
nicht aber den einer anderen Verarbeitung oder Nutzung spezifizieren. Die 
getrennte Führung des jeweiligen Zwecks erhöht die Verständlichkeit und 
reduziert die Gefahr einer unbeabsichtigten Modifikation. 


! So auch ErwGr 60 DSGVO. 

2 In der Unternehmenspraxis werden Zwecke, häufig entlang der Ebenen „strategisch, taktisch, 
operativ“, strukturiert und hierarchisiert. Festgelegte Zweckkategorien oder -gruppen werden 
durch konkrete Zweckbeschreibungen im Freitext ergänzt. Eine entsprechende hierarchische 
Systematisierung bietet sich auch für die Datenkategorien an. 

3 Gola/Schomerus, BDSG 2015, $ 34 Rn. 12. 

4 BVerfGE 100, 313 (360). 

5 Dix in: Simitis, BDSG 2014, § 34 Rn. 31. 

6 Für Dix in: Simitis, BDSG 2014, $ 34 Rn. 31 ist die präzise, zweckspezifische Fassung des 
Dateinamens ausreichend. 
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3.7 Umfang des Rechts auf Auskunft 


Für die Rechtsgrundlage des Umgangs mit personenbezogenen Daten besteht 
keine explizite Auskunftspflicht.! Ist sie jedoch nicht aus dem Zweck ersichtlich, 
erhöht eine Nennung die Klarheit und reduziert die Wahrscheinlichkeit von 
Rückfragen. 


Die Auskunft selbst unterliegt der strengen Zweckbindung des $ 34 Abs. 5 
BDSG. $ 34 Abs. 5 BDSG ergänzt die besondere Zweckbindung des $ 31 
BDSG für die interne Datenschutzkontrolle durch eine Komponente für die 
externe Kontrolle und Transparenz. Die Regelung folgt damit der allgemeineren 
in $ 6 Abs. 3 BDSG, die Daten über die Ausübung eines Betroffenenrechtes 
selbst der Zweckbindung unterwirft. 


Die DSGVO wird die Zweckbindung etwas aufweichen. Eine Zweckänderung 
ist nach ErwGr 61 unter Benachrichtigung des Betroffenen möglich, soweit 
nach Art. 5 Abs. 1 Lit. b DSGVO der Zweck der vorgesehenen Verarbeitung 
mit dem Zweck der Erhebung vereinbar ist. 


Auf der anderen Seite erweitert Art. 15 Abs. 1 Lit. aDSGVO die Auskunft 
über den Speicherzweck auf eine Auskunft über alle Verarbeitungszwecke. 


3.7.6 Logischer Aufbau 


Der logische Aufbau der automatisierten Verarbeitung personenbezogener 
Daten ist gemäß $ 6a Abs. 3 BDSG bzw. Art. 12 Lit. a dritter Spiegelstrich 
DSRL Teil des Auskunftsanspruchs des Betroffenen. Der deutsche Gesetzgeber 
hat sich zu einer Minimalumsetzung der Richtlinie 95/46/EG entschieden.” 
Die in der DSRL vorgesehene Transparenz über Verarbeitungsvorgänge wird 
weitestmöglich beschränkt.” Nach dem Wortlaut der Richtlinie ist der logische 
Aufbau automatisierter Verarbeitung „zumindest im Fall automatisierter Ent- 
scheidungen“ zu beauskunften. Im deutschen Datenschutz ist dieses Recht im 
erweiterten Auskunftsanspruch des $ 6a Abs. 3 BDSG verwirklicht. 


l Dix in: Simitis, BDSG 2014, $ 34 Rn. 31. 
2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 20. 
3 Dies wird durch Art. 15 Abs. 1 Lit. h DSGVO aufrechterhalten. 


81 


3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


Der logische Aufbau einer automatisierten Verarbeitung ist nicht selbst perso- 
nenbezogenes Datum. Der diesbeziigliche Auskunftsanspruch weicht insofern 
von den übrigen Auskunftsansprüchen aus § 19 Abs. 1 S. 1 sowie § 34 Abs. 
1 S. 1 BDSG ab. Diese beziehen sich allesamt direkt auf personenbezogene 
Daten. 


Zu beauskunften sind die tragenden Funktionsprinzipien des logischen Aufbaus, 
nicht technische Einzelheiten (Algorithmen).! Der Betroffene muss die in das 
Verfahren eingehenden Informationen und die Ableitung des Endergebnisses 


nachvollziehen kénnen.2 


Mit Rücksicht auf Geschäftsgeheimnisse (siehe Abschnitt 3.8) muss die Aus- 
kunft keine Angaben über die verwendete Software enthalten.” 


Zu beauskunften sind die berechneten Wahrscheinlichkeitswerte beim Scoring 
(§ 34 Abs. 2S. 1 Nr. 1, Abs. 4 S. 1 Nr. 1 u. 2 BDSG), ihr Zustandekommen ($ 34 
Abs. 2 S. 1 Nr. 3, Abs. 4 S. 1 Nr. 4 BDSG) und gemäß § 34 Abs. 2 S. 1 Nr. 2, Abs. 
4 S. 1 Nr. 3 BDSG zumindest auch die Art der für die Berechnung verwendeten 
Daten. Aus $ 34 Abs. 2 S. 1 Nr. 3, Abs. 4 S. 1 Nr. 4 BDSG ergibt sich, 
dass für die konkrete Berechnung der Wahrscheinlichkeitswerte eine alleinige 
Angabe der Datenkategorien nicht ausreicht. Die Auskunftsverpflichtung 
umfasst alle eingegangenen Einzeldaten, um dem Betroffenen die Möglichkeit 
an die Hand zu geben, die Berechnung anhand der eingeflossenen Parameter 
nachzuvollziehen.* Auf der Output-Seite ist die Werteskala der Ergebnisse Teil 
des Auskunftsanspruchs.° 


Die eigentliche Scoreformel, der Algorithmus, ist nicht zu beauskunften.° Ob 
Auskunft tiber die Gewichtung der Eingangsfaktoren und die Zuordnung des 


1 Mackenthun in: Taeger/Gabel, BDSG 2013, BDSG § 6a Rn. 23. 

? Scholz in: Simitis, BDSG 2014, § 6a Rn. 39; RoBnagel 2003, Kap. 9.2 Rn. 138. 
3 BT-Drs. 14/4329, 38. 

4 BGH, NIW 2014, 1235 (1236). 

5 Dix in: Simitis, BDSG 2014, § 34 Rn. 33. 

6 BGH, NJW 2014, 1235 (1237). 
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3.7 Umfang des Rechts auf Auskunft 


Betroffenen zu einer Vergleichsgruppe zu erteilen ist, ist in der Literatur um- 
stritten.! Der BGH folgt jedoch der Auffassung, dass keines von beidem Teil des 
Auskunftsanspruchs ist.” Die branchenspezifische Scorecard, die einzelfallun- 
abhängig statistische Größen, Vergleichsgruppen und Berechnungsmodalitäten 
festlegt, ist dem Betroffenen nicht zugänglich. Eine andere Interpretation würde 
das Auskunftsrecht des Betroffenen zulasten des Betriebs- und Geschäftsge- 
heimnisses des Scoring-Unternehmens über das vom Gesetzgeber gewünschte 
Maß ausdehnen.? Eine Auskunft über einzelfallunabhängige Elemente der 
Scoreberechnung würde dem Betroffenen auch keine Wahrnehmung weiterer 
Betroffenenrechte ermöglichen, da ihnen der Personenbezug fehlt.* 


Der Auskunftsanspruch für das Scoring fällt damit hinter den Auskunftsan- 
spruch über den logischen Aufbau einer Verarbeitung im Falle einer automati- 
sierten Einzelfallentscheidung zurück. Kommen Scoring und automatisierte 
Entscheidung ohne weitere inhaltliche Prüfung zusammen, und kann bei- 
des als ein einheitlicher Verarbeitungsschritt verstanden werden, kommt der 
weitgehendere Auskunftsanspruch zum logischen Aufbau zum Zuge.> 


Unter Berücksichtigung der abweichenden Intention der DSRL wird schon seit 
längerem eine Ausweitung des Auskunftsrechts zum logischen Aufbau auf jede 
automatisierte Datenverarbeitung, insbesondere in komplexen, arbeitsteiligen 
Verarbeitungsprozessen,° vorgeschlagen.’ Die Auskunft sollte entsprechend 
der technischen Entwicklung nicht mehr Abbild eines statischen Zustands sein. 
Ein umfassender, dynamischer Begriff der Verarbeitung und daraus folgende 
prozessorientierte Auskunftsansprüche sind geboten. 


1 Stellvertretend für die Auskunftspflicht Dix in: Simitis, BDSG 2014, $ 34 Rn. 33; die Gegenauf- 
fassung wird u.a. von OLG Nürnberg, ZD 2013, 26 (27), vertreten. 

2 BGH, NJW 2014, 1235 (1237). 

3 BGH, a. a. O. 

4 BGH, a. a. O. 

5 BGH, NJW 2014, 1235 (1238). 

6 Weichert, DuD 2006, 694 (698 f.). 

7 Roßnagel/Pfitzmann/Garstka 2001, 171. 
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3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


3.7.7 Recht auf Negativauskunft 


Eine Negativauskunft ist eine Bestätigung des Sachverhalts, dass durch die 
verantwortliche Stelle keine personenbezogenen Daten des Auskunftsersu- 
chenden gespeichert werden oder wurden. Überwiegend wird ein Recht auf 
solch eine Negativauskunft zugestanden.! Dreh und Angelpunkt ist die Frage, 
ob es bei einer Negativauskunft überhaupt einen Betroffenen bzw. perso- 
nenbezogene Daten gibt. Nach dem Gesetzeswortlaut wäre dann auch das 
Recht auf Auskunft nicht einschlägig. Weichert argumentiert jedoch zutreffend, 
dass die Betroffenheit im Falle der Transparenz weiter zu fassen ist.” Denn 
betroffen ist der, dessen Persönlichkeitsrechte beeinträchtigt werden. Und 
wie soll der einzelne sich vollkommen frei bewegen können, wenn er einer 
gegenwärtig nicht vorhandenen Beobachtung nicht gewahr werden kann? Auch 
die europarechtskonforme Auslegung lässt keinen anderen Schluss zu. Art. 12 
Lit. a erster Spiegelstrich der DSRL beinhaltet einen expliziten Anspruch auf 
Negativauskunft. 


3.8 Entgegenstehende Interessen 


3.8.1 Geschäfts- und Betriebsgeheimnisse 


Die Berücksichtigung von Geschäfts- und Betriebsgeheimnissen nicht- 
öffentlicher verantwortlicher Stellen bei der Bestimmung des Umfangs einer 
zu erteilenden Auskunft ist verfassungsrechtlich geboten (siehe Kapitel 2.1). 
Sie stützt sich europarechtlich auf Art. 13 Abs. 1 Lit. g DSRL. Danach sind 
Ausnahmen zum Schutz der Rechte und Freiheiten anderer Personen möglich.’ 


! Weichert, NVwZ 2007, 1004; Dix in: Simitis, BDSG 2014, § 34 Rn. 18; Mallmann in: Simitis, 
BDSG 2014, § 19 Rn. 23; AG Leipzig, BeckRS 2014, 14721; Gola/Schomerus, BDSG 2015, $ 
19 Rn. 4 — Allerdings: ablehnend in Gola/Schomerus, BDSG 2015, § 34 Rn. 5a. 

2 Weichert, NVwZ 2007, 1004 (1004). 

3 Siehe auch ErwGr 41 DSRL. 
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3.8 Entgegenstehende Interessen 


Der deutsche Gesetzgeber hat im Rahmen von § 34 Abs. 1 S. 4 BDSG davon 
Gebrauch gemacht, eine besondere Ausnahme für die Angabe von Herkunft 
und Empfänger einzuführen. Die Auskunft zu Herkunft und Empfänger legt 
Geschäftsbeziehungen und Geschäftsprozesse offen.! Sie „kann verweigert 
werden, soweit das Interesse an der Wahrung des Geschäftsgeheimnisses ge- 
genüber dem Informationsinteresse des Betroffenen überwiegt.“ Die Regelung 
findet sich redundant auch in $ 34 Abs. 3 S. 3 BDSG. 


Die Abwägung der Interessen der verantwortlichen Stelle und des Betroffenen 
ist einzelfallspezifisch. Während es grundsätzlich keinen Vorrang von Grund- 
rechten untereinander gibt, wird einfachgesetzlich das Recht auf informationelle 
Selbstbestimmung dem Schutz von Geschäftsgeheimnissen vorgezogen. 


Die Kenntnis der Herkunft ist entscheidend, um datenschutzrechtliche Be- 
troffenenrechte und zivilrechtliche Ansprüche (z. B. Schadenersatz) geltend 
machen zu können. Insbesondere wenn zum Entstehungszeitpunkt falsche 
Informationen oder sogar verleumdende Aussagen in die Welt gesetzt wur- 
den, muss der Betroffene die Möglichkeit haben, gegen den ursprünglichen 
Verursacher vorzugehen. Entsprechende Schritte erfordern eine Kenntnis des 
Verantwortlichen. 


Die Geheimhaltung der Geschäftsbeziehung kann nur dann verhältnismäßig 
sein, wenn „keine begründeten Zweifel an der Richtigkeit der Daten bestehen“? 
und in einer Einzelfallabwägung davon ausgegangen werden kann, dass das 
Geheimhaltungsinteresse der verantwortlichen Stelle das Auskunftsinteresse 
des Betroffenen aufgrund besonderer Umstände überwiegt. In Grenzfällen kann 
eine Begründung des Informationsinteresses vom Betroffenen eingeholt werden, 
um eine Letztentscheidung zu treffen.” Beschließt die verantwortliche Stelle im 
Ergebnis die Verweigerung der Auskunft über Empfänger personenbezogener 
Daten, muss sie diesen Beschluss in jedem Einzelfall stichhaltig begründen. 4 


' BT-Drs. 4306, 51. 

2 Dix in: Simitis, BDSG 2014, § 34 Rn. 27. 

3 Dix in: Simitis, BDSG 2014, § 34 Rn. 27; Sydow, NVwZ 2013, 467 (470). 
4 LfD Hessen, 30. Tätigkeitsbericht, LT-Drs. 15/4659, 40. 
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3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


Kategorien von Empfängern genießen den Schutz aus § 34 Abs. 1 S. 4 BDSG 
nicht.! Sie fassen tatsächliche Geschäftsbeziehungen so weit zusammen, dass 
sie als anonymisiert gelten können. Eine Ableitung der geschäftlichen Gepflo- 
genheiten der verantwortlichen Stelle sind nur noch rudimentär möglich. Die 
Informationen sind insofern zumindest nicht mehr in einem Maße schützens- 
wert, dass es gegenüber dem Interesse des Betroffenen überwiegt. Auch die 
geschäftlichen Interessen des Empfängers werden nicht berührt. Er ist in zu 
Kategorien zusammengefassten Empfängerlisten nicht mehr kenntlich. 


Nicht-rechtliche Interessen von Informanten und anderen Quellen personenbe- 
zogener Daten sind nicht Teil der Interessenabwägung.” Wenn die Interessen 
eines Dritten Teil der Interessen der verantwortlichen Stelle werden, sind sie in 
die Interessenabwägung miteinzubeziehen.* 


Die Erklärung von allgemeinen personenbezogenen Daten zu schützenswerten 
Geschäftsgeheimnissen, die in die Abwägung mit einzubeziehen sind, würde 
im Extremfall dazu führen, dass gar keine Auskunft möglich wäre. Gemäß 
§ 34 Abs. 7 BDSG i. V. m. § 33 Abs. 2 Satz 1 Nr. 7 b) BDSG kann aufgrund 
des Geschäftsgeheimnisses eine Auskunft insgesamt unterbleiben, wenn die 
Auskunft „die Geschäftszwecke der verantwortlichen Stelle erheblich gefährden 
würde, es sei denn, dass das Interesse an der Benachrichtigung die Gefährdung 
überwiegt.“ 


Die Fähigkeit in Kombination mit der Möglichkeit zur Profilbildung, ist der 
Hauptwettbewerbsvorteil* vieler Internetunternehmen wie Suchmaschinen oder 
sozialer Netzwerke. Sie war es schon immer für Anbieter von Kreditscoring- 
verfahren. Nur wer Zugriff auf umfangreiche personenbezogene Datenmassen 
besitzt und gleichzeitig die notwendigen Algorithmen beherrscht, kann sie 
zu Profilen zusammenführen. Folglich sind neben den Algorithmen auch 
die personenbezogenen Rohdaten in manchen Fallkonstellationen Betriebs- 
und Geschäftsgeheimnisse. In der Interessenabwägung überwiegt jedoch im 


! Dix in: Simitis, BDSG 2014, $ 34 Rn. 25. 

? LG Ulm, Urteil vom 1.12.2004, MMR 2005, 265, 266. 

3 Dix in: Simitis, BDSG 2014, $ 34 Rn. 28. 

* Alleinstellungsmerkmal eines Unternehmens im Wettbewerb; häufig auch engl. als Unique 
Selling Proposition bzw. Point (USP) bezeichnet. 
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3.8 Entgegenstehende Interessen 


Allgemeinen das Auskunftsinteresse des Betroffenen.! Im Speziellen ist die 
wettbewerbliche Bedeutung der Daten miteinzubeziehen.” Wahrscheinlich- 
keitswerte im Scoring zählen, im Gegensatz zur Scoreformel selbst, nicht als 
Betriebs- und Geschäftsgeheimnisse.? 


3.8.2 Persönlichkeitsrechte Dritter 


Medizinische Daten Dem gesteigerten Interesse des Patienten an der Kennt- 
nis medizinischer Daten steht das berechtigte Interessen des behandelten Arztes 
gegenüber, persönlich gefärbte Aufzeichnungen geheim zu halten. Auch kann 
die Bekanntgabe einer Diagnose oder erwarteten Patientenverhaltens Einfluss 
auf den Behandlungserfolg haben.* Deshalb schränkt die Rechtsprechung 
die Rechte des Betroffenen auf bewertungsneutrale, naturwissenschaftlich- 
objektive Aufzeichnungen ein.” Subjektive Wertungen des behandelnden Arztes 
sind ausgenommen.® Dies gilt jedoch nicht, sobald die Wertungen in Dateien 
aufgenommen werden und das datenschutzrechtliche Auskunftsrecht greift. 
In diesem Fall sind auch die Beurteilungen des Arztes mitzubeauskunften.’ 
Möchte der behandelnde Arzt persönliche Gedanken geheim halten, hat er sie 
außerhalb der Patientenakte aufzubewahren und entsprechend zu kennzeich- 


nen. 8 


Veröffentlichung personenbezogener Daten in Telemedien Werden perso- 
nenbezogene Daten einer Person durch eine Organisation auf deren Webseite 
veröffentlicht und zum Abruf bereitgehalten, handelt es sich nach $ 3 Abs. 4 


! BGH, NJW 2014, 1235 (1236). 

? Spiecker genannt Döhmann 2009, 40 f. 

3 Dix in: Simitis, BDSG 2014, $ 34 Rn. 33. 

4 Eine Vortäuschung von Therapieerfolgen durch den Patienten ist dagegen kein grundrechtlich 
gerechtfertigter Einschränkungsgrund. — BVerfG, NJW 2006, 1116 (1121). 

5 BGH, NJW 1985, 674 (675). 

6 BGH, NJW 1983, 328 (330) bestätigt durch BVerfG, NJW 1999, 1777. Zur entstehenden 
Abwägungsproblematik siehe auch die Anmerkungen in Abschnitt 3.8.4. 

7 Scheiwe 1998, 324. 

8 Scheiwe 1998, 326. 
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3 Einfachgesetzliche Verankerung des Rechts auf Auskunft 


Nr. 3 b) BDSG um eine Ubermittlung, sobald ein Dritter auf die Daten zu- 
greift. Dabei ist unerheblich, ob die personenbezogenen Daten aufgrund der 
Einwilligung des Betroffenen nach § 4a BDSG oder aufgrund einer anderen 
Rechtsgrundlage online gestellt werden. 


Personenbezogene Daten werden von Unternehmen auf ihrem Internetauftritt 
präsentiert, um unter anderem Ansprechpartner zu benennen (Mitarbeiterfotos, 
Namen, u.ä.) oder für eine positive Außendarstellung zu sorgen (Fotos zufrie- 
dener Kunden, positive Nutzerkommentare). Staatliche Stellen haben ähnliche 
Motive. 


Neben den veröffentlichten Daten selbst haben auch die Kommunikationsbe- 
ziehungen zwischen der verantwortlichen Stelle und den abrufenden Dritten 
einen Bezug zu der Person, deren Daten veröffentlicht wurden (im Folgenden: 
referenzierte Person). Der Umgang mit personenbezogenen Daten stellt einen 
faktischen Personenbezug her (siehe Abschnitt 3.7.1). Ist der Dritte eine na- 
türliche Person, entsteht ein doppelter Personenbezug. Der Abruf der auf der 
Webseite veröffentlichten Daten wäre damit zunächst sowohl gegenüber dem 
Abrufenden, als auch gegenüber der referenzierten Person zu beauskunften. 


Der Auskunftsanspruch des Abrufenden kann sich auf $ 13 TMG stützen, der 
der referenzierten Person auf $ 34 BDSG. Wäre die verantwortliche Stelle 
redaktionell-journalistisch tätig, würde die Auskunft den Bedingungen des $ 57 
Abs. 2 RStV unterliegen.! Der Anspruch gegenüber dem Infrastrukturanbieter 
über die Metadaten der elektronischen Kommunikation nach $ 93 TKG soll 
außen vor bleiben. 


Bei diesem doppelten Auskunftsanspruch entsteht eine Gemengelage unter- 
schiedlicher Interessen. Aus Sicht des Zugreifenden besteht keine Veranlassung, 
seinen Abruf der Webseite zu erfassen. Eine anonyme Nutzung des Telemedien- 
dienstes gemäß $ 13 Abs. 6 TMG würde seinen Interessen am ehesten gerecht. 
Insofern keine Erhebung personenbezogener Daten über das Faktum des 
Zugriffs stattfindet, wäre dementsprechend auch keine Auskunft erforderlich. 


' Weichert, VuR 2009, 323 (329). 
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3.8 Entgegenstehende Interessen 


Erst durch einen möglichen Auskunftsanspruch der referenzierten Person 
könnte ein legitimer Zweck zur Erhebung und Verarbeitung der Metadaten 
des Kommunikationsvorgangs entstehen. Da der Abrufende Empfänger per- 
sonenbezogener Daten des Dritten ist, ist entsprechend der Ausführungen in 
Abschnitt 3.7.2 ein Auskunftsanspruch zu bejahen. 


Die im Recht auf informationelle Selbstbestimmung verankerten Rechte auf 
Anonymität und auf Kenntnisnahme zweier Grundrechtsberechtigter dürfen 
sich jedoch nicht gegenseitig ausschließen. Sie sind in einer Gesamtsicht in 
Einklang zu bringen, die die Rechte aller Beteiligter in Ausgleich bringt. Hat 
die referenzierte Person der Veröffentlichung ihrer personenbezogenen Daten 
zugestimmt oder wurde sie darüber unterrichtet, kann sie mit einer Vielzahl 
von Zugriffen auf ihre personenbezogenen Daten rechnen. Es ist praktisch 
jedem Dritten möglich, von diesen personenbezogenen Daten Kenntnis zu 
nehmen. Ein detaillierter Auskunftsanspruch der referenzierten Person würde 
dieser daher ein Wissen über ihre öffentliche Sphäre zukommen lassen, das 
dem öffentlichen Charakter der personenbezogenen Daten nicht angemessen 
ist. Der Auskunftsanspruch würde zu einer mittelbaren Totalüberwachung 
Dritter führen. Dies widerspricht dem Geist des Rechts auf informationelle 
Selbstbestimmung, das immer in seinem sozialen Kontext betrachtet werden 
muss. Das Recht der abrufenden Person auf Anonymität wiegt hier stärker. 


Den Interessen der referenzierten Person kann dadurch nachgekommen werden, 
dass über den Tatbestand der Veröffentlichung in allgemeiner Form informiert 
wird. Die Angabe von Beginn und Ende der Veröffentlichung berührt keine 
Interessen Dritter und stellt eine wertvolle Information dar. Soweit allgemeine 
Informationen über Zugreifende in statistisch-anonymisierter Form gesammelt 
werden, zum Beispiel gruppiert nach Ländern, sind auch diese zu beauskunften. 


Wäre der Dritte jedoch keine natürliche Person, sondern eine juristische, würde 
das Recht auf Anonymität entfallen. Es könnte daher von der verantwortlichen 
Stelle gefordert werden, diejenigen Zugriffe zu speichern und zu beauskunften, 
die nicht durch natürliche Personen erfolgt sind. Das Ergebnis wäre jedoch, dass 
die verantwortliche Stelle für jede IP-Adresse überprüfen müsste, wem diese 
zuzuordnen ist. Im Endeffekt würde dies dazu führen, dass den zugreifenden 
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natürlichen Personen keine anonyme oder pseudonyme Nutzung mehr möglich 
ist. 


Anders stellt sich die Situation bei erst nach Login verfiigbaren Daten dar. Ein 
Zugriff auf solche hat Einzelfallcharakter, ist mit einer Veröffentlichung nicht 
zu vergleichen und immer zu beauskunften. 


Eine Protokollierung zu Datensicherungszwecken führt zu weiteren Abwägungs- 
problemen. In diesem Fall entsteht ein Auskunftsanspruch der zugreifenden 
Person. Entgegenstehende Interessen der referenzierten Person bestehen nicht. 
Ein Auskunftsanspruch der referenzierten Person würde jedoch auch wieder 
zu einer über die Datensicherung hinausgehenden Überwachungsmöglichkeit 
führen. Es liegt nahe, dass deshalb auch in diesem Szenario kein detaillierter 
Auskunftsanspruch zugebilligt wird. 


3.8.3 Weitere Ausnahmen von der Auskunftspflicht 


Neben den Regularien zu Geschäfts- und Betriebsgeheimnissen und den 
erwähnten Konflikten zwischen Persönlichkeitsrechten Dritter bestehen weitere 
Ausnahmen von der Auskunftspflicht nicht-dffentlicher Stellen gemäß $ 34 
Abs. 7 BDSG i. V.m. § 33 Abs. 2 S. 1 


e Nr. 2 für die Speicherung aufgrund gesetzlicher Aufbewahrungsvor- 
schriften bei unverhältnismäßigem Aufwand der Auskunft, sowie die 
Speicherung zur Datensicherung oder Datenschutzkontrolle, insbeson- 
dere Protokolldaten; 


e Nr. 3 falls die Geheimhaltung wegen des überwiegenden Interesses eines 
Dritten erforderlich ist; ! 


e Nr. 5 in der wissenschaftlichen Forschung bei unverhältnismäßigem 
Aufwand der Auskunft; 


' Bspw. im Falle der anwaltlichen Schweigepflicht - AG Köln, NJW 2015, 1701 (1701). 
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e Nr. 6 falls die öffentliche Sicherheit und Ordnung oder das Wohl des 
Bundes beziehungsweise eines Landes gefährdet ist; 


e Nr. 7 a) wenn die Speicherung für eigene Zwecke erfolgt, die Daten aus 
allgemein zugänglicher Quelle bezogen wurden und die Auskunft einen 
unverhältnismäßigem Aufwand erfordern würde. 


Für öffentliche Stellen ist die Auskunft über die Übermittlung an Sicherheitsbe- 
hörden nach $ 19 Abs. 3 BDSG von deren Zustimmung abhängig. Des Weiteren 
gibt es zum Auskunftsrecht gegenüber Sicherheitsbehörden spezialgesetzliche 
Regelungen. ! 


Die in $ 19 Abs. 4 BDSG aufgeführten Auskunftsverbote reduzieren den 
Ermessensspielraum der öffentliche Stellen sogar auf Null.” 


Analog der Regelung für nicht-Öffentliche Stellen kann nach $ 19 Abs. 2 BDSG 
das Recht auf Auskunft für personenbezogene Daten, die ausschließlich zu 
Zwecken der Datensicherung oder der Datenschutzkontrolle gespeichert wer- 
den, eingeschränkt werden, soweit durch die Auskunft ein unverhältnismäßiger 
Aufwand entstehen würde. Der Begriff der Datensicherung umfasst alle Maß- 
nahmen der Datensicherheit nach $ 9 BDSG, also auch Mißbrauchsprävention 
und -kontrolle.* 


Zu einem anderen Ergebnis kommt man fiir die Ausnahme des § 33 Abs. 2 
Satz 1 Nr. 3 und 7 a) BDSG, die ebenfalls einen unverhältnismäßig hohen 
Aufwand voraussetzt. Sie kann aufgrund des Einzelfallcharakters der Auskunft 
im Regelfall nicht geltend gemacht werden.* Ein erhöhter Aufwand kann im 
Allgemeinen nur bei der Benachrichtigung als proaktive, und hierdurch in 
der Frequenz häufigere, Transparenzmaßnahme auftreten. Die verantwortliche 


! Für die Nachrichtendienste des Bundes in $ 15 BVerfSchG, auf den § 9 MADG und $ 7 BNDG 
verweisen. 

2 Mallmann in: Simitis, BDSG 2014, $ 19 Rn. 75 m. w.N. in Fn. 147. 

3 LAG Hessen, Urteil vom 29.01.2013, BeckRS 2013, 67364. 

4 BVerfGE 113, 26 (60); Dix in: Simitis, BDSG 2014, $ 34 Rn. 59. 
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Stelle hat ihre Prozesse effizient, kostensparend und auskunftsfreundlich zu ge- 
stalten.! An einer solchen hypothetischen Gestaltung, nicht an den tatsächlichen 
Abläufen und Strukturen, ist der Aufwand zu bemessen.?” 


Die Verhältnismäßigkeitsprüfung kann bei Massenauskunftsersuchen und 
anderen konzentrierten Aktionen anders ausfallen, als im Regelfall.* Im Falle 
einer missbräuchlichen Verwendung des Auskunftsrechts überwiegen die 
Interessen der verantwortlichen Stelle an einem ungestörten Betrieb und der 
Verhinderung einer Ausforschung. 


Die in $ 33 Abs. 2 Satz 1 Nr. 2 sowie $ 19 Abs. 2 BDSG mögliche Aufwands- 
abschätzung umfasst zusätzlich noch die in sich hohe Zahl der Operationen bei 
der Protokollierung. Sie wird begleitet durch die strenge Zweckbindung der 
Speicherung von, zur Datensicherung oder Datenschutzkontrolle erzeugten, 
Protokollen. Der Aufbau von Protokollen und Metadaten, insbesondere wenn 
sie für den Auskunftsanspruch selbst erzeugt und gespeichert werden, bietet 
keinen eigenen Mehrwert für den Betroffenen. Er ist implizit in der Auskunft 
über die Basisdaten enthalten. Die interne Struktur und Verknüpfungen zwi- 
schen Protokollen sind nicht zusätzlich zu beauskunften.* Gleiches gilt für den 
logischen Aufbau von Datenschutzauskunftssystemen. 


Zusammengefasst ist festzustellen, dass die weitgehenden Ausnahmen dem 
eigentlichen Transparenzanspruch des Rechts auf Auskunft zuwiderlaufen. Sie 
verkomplizieren das Recht auf Auskunft.” Ansätze, die Ausnahmetatbestände 
stark zu reduzieren, sind bisher gescheitert.° Im Grundsatz ist eine restriktive 
Interpretation der Ausnahmen erforderlich. ’ 


L Sydow, NVwZ 2013, 467 (470). 

2 BSG, NVwZ 2013, 526 (528). 

3 OVG Bremen, NJW 1987, 2393 (2396, 2398). 

4 LAG Hessen, Urteil vom 29.01.2013, BeckRS 2013, 67364. 
5 Roßnagel/Pfitzmann/Garstka 2001, 172. 

6 Beispielsweise im Reformentwurf 2001, BT-Drs 14/4329, 18. 
7 Dix in: Simitis, BDSG 2014, $ 34 Rn. 62. 
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3.8.4 Anforderungen an den Abwägungsprozess im 
Einzelfall 


Trifft die verantwortliche Stelle allein die Abwägung zwischen zu beauskunften- 
den und nicht zu beauskunftenden Informationen, entsteht ein problematisches 
Entscheidungsmonopol.! Durch die a priori vorhandene Informationsasym- 
metrie bleibt es für den Betroffenen unüberprüfbar, welche Informationen 
ihm vorenthalten wurden. Deshalb sind ablehnende Entscheidungen von der 
verantwortlichen Stelle immer umfangreich zu begründen. ? 


Wenn über berechtigte Interessen Dritter entschieden werden muss, sind Interes- 
senkollisionen kaum zu vermeiden. Fürsorgepflichten gegenüber gegenwärtigen 
oder ehemaligen Mitarbeitern der verantwortlichen Stelle, insbesondere wenn 
es sich um den Schutz vor Strafverfolgung oder zivilrechtlichen Ansprüchen 
handelt, sind kein berechtigter Grund, um von einer Auskunft über Empfänger 
personenbezogener Daten abzusehen.’ 


3.9 Zwischenfazit 


Das Recht auf Auskunft ist eng in die Systematik des Datenschutzes, insbeson- 
dere der Transparenz- und Betroffeneninterventionsrechte, eingebunden. 


Die Bestimmungen über Umfang, Reichweite und Voraussetzungen des Rechts 
auf Auskunft sind ausgesprochen umfangreich. Sie werden in Kapitel 4.3 
wieder aufgegriffen und zusammengefasst. 


Hervorzuheben ist, dass der Empfängerbegriff, bestätigt durch die DSGVO, 
zu einem Anspruch auf Auskunft über die vollständige, durchgängige Verar- 
beitungskette eines personenbezogenen Datums führt.* Für jede Erhebung, 
Verarbeitung oder Nutzung muss klar sein, woher die personenbezogenen 


! Scheiwe 1998, 316. 

2 Dix in: Simitis, BDSG 2014, $ 34 Rn. 61; Gola/Schomerus, BDSG 2015, $ 34 Rn. 19. 
3 LfD Baden-Württemberg, 31. Tätigkeitsbericht 2012/13, 145. 

4 Vgl. Abschnitt 3.7.2. 
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Daten kamen und wohin sie weitergegeben wurden. In allen Schritten ist der 
Zweck als Prüfstein der Rechtmäßigkeit sichtbar zu machen. Der Betroffene 
hat das in Hypothese 92 angenommenen Recht. 
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4  Datenschutzrechtliche 
Anforderungen an ein 
Datenschutzauskunftssystem 


Anforderungen an ein Datenschutzauskunftssystem sind vielschichtig. Funktio- 
nalen Anforderungen, wie sie sich aus Umfang und Reichweite des Rechts auf 
Auskunft ergeben, stehen neben nicht-funktionale Anforderungen, hergeleitet 
aus den allgemeinen Prinzipien des Datenschutzrechts. Sie sind gleichzei- 
tig zu berücksichtigen. Die strukturierte Ableitung der Anforderungen ist 
entscheidend, um zu einem vollständigen Anforderungsprofil zu kommen. 


Dieses Kapitel stellt ein neues Modell zur Ableitung rechtlicher Anforderungen 
vor (Abschnitt 4.1) und präsentiert die Anwendung auf die Anforderungen 
an ein Datenschutzauskunftssystem. Daraus entsteht eine Aufstellung daten- 
schutzrechtlicher Kriterien (Abschnitt 4.3) und technischer Anforderungen 
(Abschnitt 4.4), an der die Umsetzung des Datenschutzauskunftssystems ge- 
messen werden kann. ! 


4.1 Top-Down Ableitung von Anforderungen an 
ein Datenschutzauskunftssystem 


Das Fundament der deutschen Rechtsordnung ist das Grundgesetz. Die darin ko- 
difizierten Grundrechte bilden den Ausgangspunkt einer öffentlich-rechtlichen, 
in gewissem Rahmen auch einer privatrechtlichen,” Anforderungsanalyse. 


! Ein Exkurs in die Anforderungen des koreanischen Datenschutzrechts findet sich in Anhang C.3. 
? Siehe Abschnitt 2.1.2. 
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4.1.1 Die Methode KORA 


Die Methode KOnkretisierung Rechtlicher Anforderungen (KORA)! ist ein 
mögliches Werkzeug, mit dem, ausgehend von (Grund-)Rechten, Anforde- 
rungen stufenweise hin zu technischen Gestaltungsvorschlägen konkretisiert 
werden können.” 


(Grund-)Rechte Art. 2. Abs. 1 GG 


Rechtliche Anforderungen Recht auf inform. Selbstbest. 


Rechtliche Kriterien Transparenz 
Dokumentation 


Technische Sprache 


Technische Gestaltungsziele 
Technische Gestaltungsvorschläge 


Verlaufsanzeige 


Abbildung 4.1: Die Konkretisierungsschritte der Methode KORA? (mit Beispiel) 


Nach dieser Methode ergeben sich aus den vorgeschalteten Grundrechten zu- 
nächst rechtliche Anforderungen (Abbildung 4.1). Solche Anforderungen sind 
gemäß KORA allgemeingültige Rechtsregeln, die direkt aus den Grundrechten 
entnommen werden können und keiner weiteren Ableitung bedürfen.* De facto 


1 Hammer/Pordesch/Roßnagel 1993, 46 ff. 
2 Schwenke 2006, 11 ff. 

3 Nach Schulz et al. 2011. 

4 Schwenke 2006, 13. 
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finden sich unter der Kategorie „Grundrechte“ die jeweiligen Artikelnum- 
mern des Grundgesetzes. Unter den rechtlichen Anforderungen werden die 
eigentlichen, ausformulierten Grundrechte verstanden. Die auf die rechtlichen 
Anforderungen folgenden rechtlichen Kriterien sind in ihrem Abstraktionsni- 
veau durch die Methode KORA nicht eindeutig vorgegeben. Gemeinhin werden 
hierunter die Datenschutz-Schutzziele (siehe Abschnitt 3.1) und rechtliche 
Grundgedanken (z. B. Zweckbindung) verstanden, die Lösungsvarianten offen 
lassen. ! 


Der Wechsel zur technischen Sprache erfolgt mit der Methode KORA bereits 
auf dieser sehr allgemeinen rechtlichen Ebene. Die technischen Gestaltungsziele 
der dritten Stufe beschreiben elementare Funktionen, die notwendig sind, damit 
ein technisches System den rechtlichen Kriterien gerecht wird.” Technische 
Gestaltungsziele werden in der Anwendung der Methode KORA sehr allgemein 
gehalten.’ Ihr technischer Gehalt ist nicht immer erkennbar. 


Technische Gestaltungsvorschläge als finale Stufe können nach Auffassung der 
Autoren als Teil eines Lastenhefts aufgefasst werden.* Im Gegensatz zu einem 
solchen werden jedoch Alternativvorschläge für mögliche, konkret umsetzbare 
technische Maßnahmen diskutiert, wie sie sich sonst in Pflichtenheften wieder- 
finden. Die Grenze zwischen Anforderung und Lösung wird an dieser Stelle 
durchbrochen. 


Aufgrund der genannten Kritikpunkte ergibt sich der Bedarf, die Methode 
KORA stärker auszudetaillieren, die einzelnen Stufen klarer abzugrenzen und 
auf technischer Ebene funktionale und nicht-funktionale Anforderungen klar zu 
benennen. Deshalb wurde das erweiterte Vorgehensmodell für Anforderungen 
aus dem Legalbereich (EVAL) neu entwickelt. Dieses Modell wird im folgenden 
Abschnitt beschrieben. 


' Schwenke 2006, 14. 

2 Kahlert, DuD 2014, 86 (88). 

3 Beispielsweise in Schulz et al. 2011 und Kahlert, DuD 2014, 86. 
4 Schwenke 2006, 15. 
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4.1.2 EVAL: Erweitertes Vorgehensmodell fiir 
Anforderungen aus dem Legalbereich 


Fundament des EVAL-Modells sind die Artikel des Grundgesetzes (Abbil- 
dung 4.2), die auch bei der Methode KORA an erster Stelle stehen. Aus ihnen 
ergeben sich die Grundrechte. Grundrechte sind enumerativ. Sie sind von 
Rechtsprechung und Kommentarliteratur bereits abschlieBend ausgearbeitet 
worden. Sollen datenschutzrechtliche Anforderungen erhoben werden, sind 
das Recht auf informationelle Selbstbestimmung! und das Grundrecht auf 
Gewährleistung der Vertraulichkeit und Integrität informationstechnischer 
Systeme? gesetzt. 


Anforderungen sind nicht zwingend widerspruchsfrei. Konflikte und Kon- 
kurrenzsituationen können auf jeder Stufe auftreten. In EVAL ist es immer 
zulässig, Konfliktsituationen zu erkennen und auf die darunterliegende Ebene 
durchzureichen, soweit eine Entscheidung den Detailgrad der weiteren Stufe 
benötigt. Entgegenstehende Grundrechte Dritter” haben Einfluss auf Umfang 
und Reichweite des Rechts auf Auskunft und damit teilweise auch auf die 
technische Gestaltung. Sie sind im Abwägungsprozess mitzuberücksichtigen. 


Nachfolgend werden die vier Konkretisierungsschritte der EVAL-Anforderungs- 
analyse definiert, die nicht bereits enumerativ gegeben sind. 


Definition 4.1. Rechtliche Ziele sind Rahmenvorgaben, die die Grundrechte 
präzisieren. Rechtliche Ziele lassen sich direkt auf die Grundrechte zurückfüh- 
ren und liegen nicht im Ermessen des Gesetzgebers. 


! Siehe Abschnitt 2.1.1. 
? BVerfGE 120, 274 (274). 
3 Siehe Abschnitt 2.1.5. 
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De 
DT 


Abbildung 4.2: Die EVAL-Konkretisierungsschritte (mit Beispiel) 


Konkrete Umsetzung 
Hardware/Software 


Rechtliche Ziele sind durch die Rechtsprechung des Bundesverfassungsgerichts 
vorgegeben. Durch das Bundesverfassungsgericht vorgeschlagene Umsetzungs- 
varianten der rechtlichen Ziele sind nicht Teil derselben.! Eine einfachge- 
setzliche Regelung, die der Gesetzgeber genauso hätte nicht treffen können, 


l Fakultative Regelungsvorschläge finden sich in BVerfGE 65, 1 (46); BVerfGE 100, 313 (361); 
BVerfGE 109, 279 (364) und BVerfGE 125, 260 (325 £.). 
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kann eine rechtliche Anforderung oder ein rechtliches Kriterium sein, jedoch 
kein rechtliches Ziel. Fiir den Datenschutz sind die rechtlichen Ziele bereits 
abschlieBend durch die Literatur festgelegt. Sie finden sich in Abschnitt 4.2. 


Die rechtspraktische Entscheidung des Gesetzgebers kommt auf der Ebene 
der rechtlichen Anforderungen zum Ausdruck und präzisiert im Rahmen der 
einfachen Gesetze und Verordnungen die rechtlichen Ziele. 


Definition 4.2. Rechtliche Anforderungen sind die generell-abstrakten Be- 
zeichnungen für die Gebote und Verbote, für die sich der Gesetzgeber zur 
Umsetzung der rechtlichen Ziele in Rechtsnormen entschieden hat. 


Rechtliche Anforderungen leiten sich aus den rechtlichen Zielen ab. Eine 
rechtliche Anforderung legt dar, „was“ der Normadressat zu tun oder zu unter- 
lassen hat. Angaben über Parameter wie Häufigkeit, Zeitpunkt oder Umfang 
eines Tuns oder Unterlassens sind keine rechtlichen Anforderungen, sondern 
rechtliche Kriterien. Die in der gegenwärtigen Gesetzgebung niedergelegten 
datenschutzrechtlichen Anforderungen finden sich in Abschnitt 4.2. Zukünftige 
rechtliche Entwicklungen können diese verkürzen oder erweitern. 


Definition 4.3. Rechtliche Kriterien sind Verfahrensanweisungen zu oder 
Angaben über den Umfang rechtlicher Anforderungen im Einzelfall. 


Rechtliche Kriterien konkretisieren rechtliche Anforderungen. Sie beschreiben 
die Ausgestaltung der einzelnen Anforderungen aus rechtlicher Sicht. Während 
rechtliche Anforderungen die Frage nach dem „was“ beantworten, geben 
rechtliche Kriterien vor, „wie“ die Umsetzung der rechtlichen Anforderungen 
auszugestalten ist. 


Rechtliche Kriterien befinden sich in etwa auf der Ebene von User Requirements 
oder Soft Requirements.' Sie sind aus der Perspektive des Rechts formuliert. 
Da eine technische oder organisatorische Umsetzung noch offen gehalten wird, 


! Maiden 2008. 
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sprechen rechtliche Kriterien im Regelfall nicht von konkreten Daten oder Sys- 
temen. ! Im Gegensatz zu rechtlichen Anforderungen bedient sich die Ableitung 
rechtlicher Kriterien aus den Rechtsgrundlagen einer einzelfallspezifischen 
Exegese und Interpretation.” 


Definition 4.4. Technische Anforderungen sind die erwarteten technischen 
Eigenschaften von IT-Systemen, Kommunikationsprotokollen und Datenstruk- 
turen. 


Organisatorische Maßnahmen und Prozesse spielen auf der Ebene technischer 
Anforderungen keine Rolle mehr. Technische Anforderungen entsprechen Sys- 
tem Requirements oder Hard Requirements. Technische Anforderungen bündeln 
rechtliche Aspekte dort, wo sie aus technischer Sicht gemeinsam umgesetzt 
werden können. Andererseits differenzieren sich technische Anforderungen 
dort aus, wo ein einfacher rechtlicher Sachverhalt unterschiedliche technische 
Aspekte berührt. Die Bestimmung technischer Anforderungen erfolgt nicht 
durch rechtliche Auslegung, sondern stützt sich auf die bereits in den rechtlichen 
Kriterien manifestierten Ergebnisse derselben. 


Die technischen Anforderungen gliedern sich deshalb nicht entlang der recht- 
lichen Anforderungen, sondern entsprechend der üblichen Zweiteilung aus 
funktionalen und nicht-funktionalen Anforderungen. Die Abgrenzung ist nicht 
ganz trennscharf.* Funktionale Anforderungen sollen beschreiben, was ein 
Softwareprodukt tun soll. Nicht-funktionale Anforderungen sollen ergänzen, 
wie, also in welcher Qualität die Leistung erbracht wird.* 


In allgemeinen Softwareprojekten gehören die aus rechtlichen Kriterien ab- 
geleiteten technischen Anforderungen immer zu den nicht-funktionalen An- 
forderungen. Anders stellt sich die Situation dar, wenn die Grundfunktion des 


1 Anders bei Probst, DuD 2012, 439; Probst nimmt keine klare Trennung zwischen rechtlichen 
Anforderungen, rechtlichen Kriterien und technischen Kriterien vor. 

2 Diese wird für das Auskunftsrecht in Kapitel 3 vorgenommen. 

3 Eine Vielzahl von Definitionen im Vergleich finden sich bei Glinz 2007 und Chung/do Prado 
Leite 2009. 

* Jureta/Mylopoulos/Faulkner 2008. 
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Softwareprodukts die Erfiillung einer rechtlichen Anforderung ist. Ein Daten- 
schutzauskunftssystem hat die Grundfunktion, Datenschutzauskünfte zu ertei- 
len. Deshalb sind die, aus der rechtlichen Anforderung „Auskunftsanspruch“ 
mittelbar über rechtliche Kriterien abgeleiteten, technischen Anforderungen 
funktionaler Art. 


Um die Beziehung der Anforderungen in einem Softwareentwicklungsprozess 
zur Umwelt zu beschreiben, wurden in der Literatur Annahmen (Assumptions) 
und Fakten (Facts) eingeführt." Annahmen sind für wahr gehaltene, aber 
unbestätigte Faktoren. Fakten sind bestätigte, objektive Rahmenbedingungen. 
Annahmen und Fakten sind nicht technisch beeinflussbar und können des- 
halb limitierend wirken. Im EVAL-Vorgehensmodell werden nicht-technische 
Umweltbedingungen bereits bei der Exegese der rechtlichen Kriterien berück- 
sichtigt. Im späteren Verlauf gehen Annahmen und Fakten in die Prüfung mit 
ein, ob die Spezifikation die technischen Anforderungen erfüllt. Annahmen 
und Fakten in diesem Sinne sind von der Anforderungsanalyse unabhängig. 


Bei der Formulierung von Anforderungen muss berücksichtigt werden, dass 
eine gute Anforderung Lösungsansätze aus dem gesamten Entwurfsraum 
zulässt.” Eine Anforderung sollte so konkret wie nötig, aber so allgemein wie 
möglich formuliert werden. Ob eine formelle oder informelle Beschreibung der 
technischen Anforderungen gewählt wird, gibt das EVAL-Modell nicht vor. 
Dies ist unter anderem abhängig vom jeweiligen Softwareentwicklungsprozess 
und den organisatorischen Gegebenheiten der umsetzenden Stelle.* 


Die technische Spezifikation und die Implementierung sind nicht mehr Teil 
der Anforderungsanalyse. Die technische Spezifikation ist eine formale Model- 
lierung von Architektur, Protokollen, Datentypen und Interface-Definitionen. 


! Fabian et al. 2010. 

2 Ralph 2013. 

3 Einen Überblick über Methoden des technischen Requirements Engineering bieten Fabian et al. 
2010 und Lamsweerde 2000. Eine Einordnung formaler Modellierungsansätze für rechtliche 
Anforderungen leistet Otto/Anton 2007. Eine Übersicht über Tools zur Formalisierung rechtlicher 
Anforderungen und sich ergebender Probleme liefern Kiyavitskaya/Krausovä/Zannone 2008. 

4 Ob ein formaler Ableitungsprozess von Anforderungen auf Spezifikation und Implementierung 
praktisch möglich ist, stellen bereits Parnas/Clements 1986 in Frage, sprechen sich jedoch dafür 
aus, einen solchen Prozess zu simulieren. 
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Die Implementierung ist die Umsetzung der technischen Spezifikation in Soft- 
und/oder Hardware. 


Eine entlang des EVAL-Modells entwickeltes Datenschutzauskunftssystem hat 
den Anspruch, nicht nur rechtmäßig, sondern vorausschauend rechtsverträglich 
zu sein. 


4.2 Datenschutz-Schutzziele und 
datenschutzrechtliche Anforderungen 


Datenschutz-Schutzziele Für den Datenschutz erfüllen die 6 Datenschutz- 
Schutzziele! die Rolle der rechtlichen Ziele.” Sie konkretisieren das Recht auf 
informationelle Selbstbestimmung und das Grundrecht auf Gewährleistung 
der Vertraulichkeit und Integrität informationstechnischer Systeme ohne der 
Gestaltung des Datenschutzrechts im Einzelnen vorzugreifen. Sie haben den 
Anspruch, die Ziele der Datenschutz-Grundrechte vollständig abzubilden.’ 


Vertraulichkeit und Integrität sind Teil eines eigenen Grundrechts, des Grund- 
rechts auf Gewährleistung der Vertraulichkeit und Integrität informationstech- 
nischer Systeme. Die Forderung nach Verfügbarkeit ist die Ergänzung zum 
klassischen IT-Sicherheitsdreiklang,* spielt allerdings nur mittelbar eine Rolle 
als Verfügbarkeit transparenzsichernder Maßnahmen. 


Bedeutsam ist das Ziel der Transparenz als Recht des Einzelnen, beurteilen zu 
können, wer wann was über ihn weiß.° Die Kenntnisnahme der Maßnahmen 
zur Verwendung personenbezogener Daten ist grundrechtlich geschützt.’ 


l Rost/Pfitzmann, DuD 2009, 353. 

? Siehe Abschnitt 3.1. 

3 Bock/Meissner, DuD 2012, 425 (426). 

* CIA - Confidentiality, Integrity, Availability. 

5 BVerfGE 100, 313 (360); BVerfGE 109, 279 (379). 

6 BVerfGE 65, 1 (43); BVerfGE 125, 260 (334). 

7 BVerfGE 100, 313 (361); BVerfGE 109, 279 (363 f.); siehe auch Abschnitt 2.1.3. 
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In der Intervenierbarkeit manifestiert sich die Befugnis des Einzelnen, selbst 
über die Preisgabe und Verwendung seiner personenbezogenen Daten zu 
bestimmen.! Aus dem Ziel der Intervenierbarkeit ergibt sich die zwingende 
Beteiligung unabhängiger Datenschutzbeauftragter.” 


Unverkettbarkeit? soll verhindern, dass es staatlichen Behörden und privaten 
Organisationen möglich ist, ein umfangreiches Persönlichkeitsprofil über jeden 
Einzelnen zu erstellen.* Bisherige Definitionsversuche wie in § 5 Abs. 1 S. 
2 Nr. 5 LDSG-SH sind unscharf.” Aus diesem Grund wird in Kapitel 9 eine 
saubere Definition des Begriffs „Grad der Unverkettbarkeit‘“ vorgenommen. 


Aus datenschutzrechtlicher Sicht sind der Unverkettbarkeit insbesondere der 
Zweckbindungsgrundsatz® sowie die informationelle Gewaltenteilung inhä- 
rent. Der Begriff der Gewaltenteilung ist staatsstheoretischen Ursprungs. 
Gewaltenteilung ist die Verteilung unterschiedlicher Machtinstrumente auf 
unterschiedliche Institutionen oder Organe, um Machtmissbrauch vorzubeugen. 
Die Institutionen oder Organe haben sich auf die ihnen zugewiesenen Auf- 
gaben zu beschränken und sich nicht in den Aufgabenbereich anderer Stellen 
einzumischen. 


Insbesondere Information ist Macht. Informationelle Gewaltenteilung ist die 
Aufteilung der Erhebung und Verwendung personenbezogener Daten zu un- 
terschiedlichen Zwecken auf unterschiedliche Stellen (organisatorisch) oder 
IT-Systeme (technisch). Der informationellen Gewaltenteilung liegt das ver- 
waltungsrechtliche Abschottungsprinzip zugrunde.’ Stellen dürfen bei der 


! BVerfGE 65, 1 (43). 

2 BVerfGE 65, 1 (46); EuGH, NJW 2010, 1265. 

3 Bedner/Ackermann, DuD 2010, 323 (324) ordnen die Unverkettbarkeit der Vertraulichkeit unter, 
definieren sie allerdings analog zum in dieser Arbeit verwendeten Begriff. 

4 BVerfGE 65, 1 (42). 

5 Unverkettbarkeit wird als ein Zustand definiert, in dem „personenbezogene Daten [..] nicht oder 
nur mit unverhältnismäßig hohem Aufwand für einen anderen als den ausgewiesenen Zweck er- 
hoben, verarbeitet und genutzt werden [können].“ Dieser Definition folgt das Kompetenzzentrum 
für angewandte Sicherheitstechnologie (KASTEL) 2013. 

6 BVerfGE 65, 1 (43). 

7 BVerfGE 65, 1 (69); BVerfG, NJW 1988, 959 (961). 
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Erfüllung ihrer Aufgaben nur auf die zum jeweiligen Zweck erforderlichen In- 
formationen zugreifen.! Eine Stelle, die mit personenbezogenen Daten umgeht, 
muss räumlich, organisatorisch und personell von anderen Stellen getrennt 
werden.” Technisch verpflichtet die Gewaltenteilung dazu, dass Zugriffsrechte, 
Rollen sowie physische und logische Speicherorte nicht beliebig festgelegt 
werden. Sie sind entsprechend dem Zweck und nach dem Prinzip der Macht- 
distribution festzulegen. Die (Re-)Kombination personenbezogener Daten ist 
zu vermeiden. 


Von den genannten sechs Datenschutz-Schutzzielen spielen Transparenz und 
Unverkettbarkeit die wichtigste Rolle für den Entwurf eines Datenschutzaus- 
kunftssystems. Die beiden Schutzziele stehen in einem Spannungsverhältnis 
zueinander. Transparenz erfordert eine ergänzende personenbezogene Samm- 
lung von Protokolldaten und die Aufrechterhaltung eines Betroffenenbezuges 
für alle personenbezogenen Daten. Jedes Mehr an Daten erhöht jedoch die 
Gefahr der Verkettbarkeit. Unverkettbarkeit erfordert, personenbezogene Daten 
dauerhaft getrennt zu speichern und zu verarbeiten und möglichst keine Daten 
mit dem Betroffenen in Bezug zu setzen. Dann kann der Betroffene allerdings 
auch keine Kenntnis vom Umgang mit den Daten nehmen. Transparenz ist 
nicht sichergestellt. 


Datenschutzrechtliche Anforderungen Die rechtlichen Anforderungen er- 
geben sich im BDSG in vielen Fällen direkt aus den amtlichen Überschriften 
der Paragraphen.” Manche Paragraphen fassen jedoch mehrere Anforderungen 
zusammen,* beschreiben nur die Ausgestaltung (Kriterien) einer an anderer 
Stelle genannten Anforderung” oder wenden sich gar nicht mit Anforderungen 
oder Kriterien an die verantwortliche Stelle. Manche Anforderungen sind auch 


l Die Informationen müssen für den entsprechenden Zweck erhoben worden sein. Eine Zweckän- 
derung ist nur eingeschränkt möglich. Insofern ist die informationelle Gewaltenteilung bereits 
zum Erhebungszeitpunkt zu berücksichtigen. 

2 BVerfG, NJW 1988, 959 (960). 

3 Beispielsweise die Betroffenenrechte der $$ 33 bis 35 BDSG. 

* So wie § 4 und $ 35 BDSG. 

5 Beispielsweise § 4e BDSG fiir die Meldepflicht. 

6 Beispielsweise die Straf- und Bußgeldvorschriften der §§ 43 und 44 BDSG. 
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in mehreren Paragraphen verwurzelt.! Es gibt also keine grundsätzliche Eins- 
zu-eins-Beziehung zwischen Anforderung und Paragraph des maßgeblichen 
Gesetzes. 


Eine Kurzzusammenfassung der datenschutzrechtlichen Anforderungen und 
der rechtlichen Ziele, die sie jeweils verfolgen, findet sich in Tabelle 4.1. Für die 
Synthese der einzelnen Anforderungen, ihre Korrektheit und Vollständigkeit, 
sei auf Anhang B.1 verwiesen. 


Tabelle 4.1: Tabellarische Übersicht der datenschutzrechtlichen Anforderungen und der verfolgten 
Datenschutz-Schutzziele 


Vertraulichkeit 
Integrität 
Verfügbarkeit 
Transparenz 
Intervenierbarkeit 
Unverkettbarkeit 


Datenschutzrechtliche Anforderungen 


Datenvermeidung? 


tal 


Datensparsamkeit 


Pal 


Anonyme und pseudonyme Dienste 
Datenschutzfreundliche Grundeinstellungen 
Datengeheimnis 

Zutritts- und Zugangskontrolle 

Zugriffs- und Weitergabekontrolle 
Verfiigbarkeitskontrolle x 
Datenkorrektheit x 
Revisionssichere Protokollierung (Eingabekontrolle) x 

Recht auf Dateniibertragbarkeit 

Prinzip der Verantwortlichkeit x 
Prinzip der nicht-automatisierten Einzelentscheidung 

Einwilligung 

Einheitliche Ansprechpartner 

Datenschutzkontrolle durch unabhängige BfD 

Meldepflicht x 
Aufklarungspflichten x 
Hinweis- und Kennzeichnungspflichten x 


x KM mM OM 


MM Os 


! Häufig als Trennung zwischen öffentlichen und nicht-öffentlichen Stellen wie die $$ 19 und 34 
BDSG für den Auskunftsanspruch. 

? Einschließlich des Gebots der frühzeitigen Anonymisierung als ex post Datenvermeidung - 
BVerfGE 65, 1 (49). 
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Unterrichtungspflichten 
Benachrichtigungspflichten 

Auskunftsanspruch 

Vorabkontrolle und Datenschutzfolgenabschätzung 
Datenschutzaudit 

Informationspflichten (bei DS-Verletzungen) 
Fiihrung eines Verfahrensverzeichnisses 

Recht auf Berichtigung 

Recht auf Löschung 

Recht auf Sperrung 

Widerspruchsrecht 

Zweckbestimmung x 
Zweckbindung und Zwecktrennung 

Organisatorische und technische Gewaltenteilung 

Grundsatz der Direkterhebung x x 
Verbot mit Erlaubnisvorbehalt! 

Verhältnismäßigkeitsprinzip? 


Cae i <i i da 
>s 


aa a 


4.3 Datenschutzrechtliche Kriterien für ein 
Datenschutzauskunftssystem 


Adäquate technische und organisatorische Vorkehrungen, um im Fall einer 
Betroffenenanfrage Auskunft geben zu können, sind Erfordernisse eines ef- 
fektiven Grundrechtsschutzes.* Die DSGVO stellt in ErwGr 63 explizit den 
Anspruch auf, dass die verantwortliche Stelle einen elektronischen Fernzugang 
zu einem sicheren System bereitstellt,* das dem Betroffenen direkten Zugang 
zu seinen personenbezogenen Daten ermöglicht. Nichts anderes ist ein automa- 
tisiertes Datenschutzauskunftssystem. Denn wie in Kapitel 3.7 herausgearbeitet 


! Nicht aus den Grundrechten abgeleitet, sondern rechtspolitische Entscheidung des Gesetzgebers 
- Rudolf in: Merten/Papier, HGR IV 2011, $ 90 Rn. 28. 

? Nicht aus den DS-Grundrechten abgeleitet, sondern aus dem Rechtsstaatsprinzip des Art. 20 
Abs. 2 GG - BVerfGE 19, 342 (348 £.). 

3 BVerfGE 35, 79 (120); BVerfGE 56, 216 (238); siehe auch 2.1.3. 

4 Von Paal in: Paal/Pauly, DSGVO 2017, Art. 15 Rn. 14 als „Webfaces‘ bezeichnet. 


107 


4 Datenschutzrechtliche Anforderungen an ein Datenschutzauskunftssystem 


wurde, sind bis auf wenige Ausnahmen alle Daten, die zu beauskunften sind, 
personenbezogene Daten des Betroffenen. Manuelle Verfahren können die 
Geschwindigkeit der Informationsverarbeitung nicht bewältigen. Auskünf- 
te, die einer Datenbank mit Stammdaten entnommen sind, geben nur einen 
Teilausschnitt der tatsächlichen Speicherung, Verarbeitung und Weitergabe 
personenbezogener Daten wieder.! Informationelle Zusammenhänge werden 
immer komplexer und bedingen eine ganzheitliche Herangehensweise. Es ist 
erforderlich, ein auf Datenschutz bezogenes Systemmonitoring in ein Daten- 
schutzauskunftssystem zu integrieren, das es dem Betroffenen erlaubt, all seine 
Transparenz- und Interventionsrechte unmittelbar wirksam wahrzunehmen. ? 


Ausgehend von dieser Grundforderung nach einem automatisierten Daten- 
schutzauskunftssystem entwickeln sich die datenschutzrechtlichen Kriterien 
für die Umsetzung eines solchen Systems entlang der datenschutzrechtlichen 
Anforderungen. Der Umfang des Auskunftsanspruchs und der Umfang der 
damit einhergehenden Protokollierung ergibt sich vorwiegend aus der einfach- 
gesetzlichen Umsetzung des Rechts auf Auskunft. Weitere Kriterien können 
aus den übrigen datenschutzrechtlichen Anforderungen abgeleitet werden. 


Die überwiegende Zahl der relevanten datenschutzrechtlichen Kriterien wurde 
bereits in Kapitel 3 hergeleitet und erörtert und wird an dieser Stelle noch 
einmal prägnant zusammengefasst. Die Verweise auf die jeweiligen Abschnitte 
im Kapitel 3 finden sich beim jeweiligen Kriterium. 


Die datenschutzrechtlichen Kriterien für das Datenschutzauskunftssystem 
erheben keinen Anspruch auf generelle Vollständigkeit. Für die Kriterien, die 
sich aus den $$ 19 und 34 BDSG ergeben, stellen die Erörterungen des Kapitels 
3 dennoch eine umfassende und abschließende Einschätzung des Rechts auf 
Auskunft dar. 


Die Korrektheit der datenschutzrechtlichen Kriterien in Abschnitt 4.3.1 ergibt 
sich aus ihrer argumentativ schlüssigen Herleitung in Kapitel 3. Die Kriterien, 
die nicht dem Auskunftsanspruch entspringen, wurden in Kapitel 3 nicht 


' Weichert, DuD 2006, 694 (695). 
2 Rost/Pfitzmann, DuD 2009, 353 (356 f.). 
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alle eingehend erörtert. Einen ergänzenden Einblick in ihre Herkunft gibt 
Anhang B.2. 


Rechtliche Kriterien sind grundsätzlich als positiv-aktive Forderung formuliert. 
Eine Auflistung von Dingen, die nicht gefordert sind, also von den technischen 
Anforderungen nicht aufgegriffen werden müssen, macht keinen Sinn. Der 
Raum der Dinge, die ein Softwaresystem nicht können muss ist beliebig groß. 
Einen Sonderfall bilden bei den rechtlichen Kriterien diejenigen Kriterien, die 
ein vorhergehendes Kriterium einschränken. Die Kriterien 4 (Keine Auskunft 
bei Daten für die Datenschutzkontrolle), 16 (Kategorisierung gleichartiger 
Empfänger), 32 (Beschränkung der Auskunft zu Zeitangaben) und 54 (keine 
Auskunft bei Missbrauch) stellen Ausnahmeregelungen dar und bieten die 
Möglichkeit von einem vorhergehenden Kriterium abzuweichen und technische 
Anforderungen zu reduzieren. Ein weiterer Spezialfall ist die dem Daten- 
schutzrecht geschuldete Prohibitivfunktionalität. Gewisse Funktionen, von 
denen sonst angenommen würde, dass sie aus technischer Bequemlichkeit 
mit umgesetzt würden, werden untersagt. Solche Kriterien sind die mit der 
Nummer 40 bis 44 (Datenvermeidung), 46 (Löschung von Protokolldaten 
nach Verarbeitung), 65 (Zweckbindung bei Datenschutzkontrolle), 72 und 73 
(organisatorische und technische Gewaltenteilung). 


4.3.1 Kriterien des Auskunftsanspruchs 


Die einfachgesetzlichen Regelungen zum Auskunftsanspruch geben im We- 
sentlichen die funktionale Gestaltung und die organisatorische Einbindung 
eines Datenschutzauskunftssystems vor. Kern eines Datenschutzauskunfts- 
systems ist die Fähigkeit, den Umgang mit personenbezogenen Daten zu 
protokollieren, die Protokolle zu verwalten und dem Betroffenen angemessen 
zugänglich zu machen. An diesen Aspekten richten sich auch die Kriterien 
des Auskunftsanspruchs aus. Die Strukturierung der Kriterien erfolgt entlang 
der zu protokollierenden Vorgänge und Datenarten. Wird im Folgenden von 
Verarbeitung gesprochen, meint dies die Verarbeitung im engeren Sinne (siehe 
Glossar). 
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Umfang der Protokollierung (Allgemein) 


Die ersten sieben Kriterien geben den Rahmen vor, in dem ein Datenschutzaus- 
kunftssystem Vorgänge in informationstechnischen Systemen protokollieren 
muss, um Auskunftsansprüche im erforderlichen Umfang befriedigen zu kön- 
nen. Der Inhalt der Protokolle wird ab Kriterium 8 behandelt. 


Kriterium 1. Die Protokollierung muss sich auf alle Erhebungs-, 
Verarbeitungs-, Speicher-, Nutzungs- und Übermittlungsvorgänge erstrecken 
(Durchgängige Historie). — Abschnitt 2.1.3 


Kriterium 2. Die personenbezogenen Daten sind so zu erheben und zu 
verwenden, dass eine vollständige Beauskunftung im Nachhinein möglich ist. 
— Abschnitt 3.4 


Kriterium 3. Die Ablage personenbezogener Daten ist so zu gestalten, dass 
der Personenbezug im Zuge der Auskunft herstellbar ist, soweit er bei der 
Verwendung durch die verantwortliche Stelle herstellbar ist. > Abschnitt 3.4 


Kriterium 4. Die Speicherung, interne Weitergabe und Verarbeitung von 
personenbezogenen Daten aus Protokollen zum Zweck der Datensicherung oder 
Datenschutzkontrolle müssen nicht beauskunftet werden. — Abschnitt 3.8.3 


Kriterium 5. Eine erteilte Auskunft ist selbst zu protokollieren und zu beaus- 
kunften. — Abschnitt 3.7.1 


Kriterium 6. Die Speicherfrist der auskunftsrelevanten Teile! der Protokolle 
muss grundsätzlich mindestens der Speicherdauer der Basisdaten entsprechen. 
— Abschnitt 3.6 


Kriterium 7. Identifikatoren Auskunftsberechtigter? dürfen erst gelöscht 
werden, wenn auch alle übrigen Protokolldaten, die personenbezogene Daten 
des Auskunftsberechtigten betreffen, gelöscht werden. — Abschnitt 3.4 


! Welche Informationen auskunftsrelevant sind, wird in den nachfolgenden Abschnitten erläutert. 
? Mögliche Identifikatoren werden in Kapitel 3.7.1 beschrieben. 
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Umfang der Protokollierung (Gespeicherte personenbezogene Daten) 


Die Kriterien 8 bis 12 beschreiben, welche Informationen über gespeicherte 
personenbezogene Daten ein Datenschutzauskunftssystem vorhalten muss. 


Kriterium 8. Der Auskunftsanspruch umfasst die gespeicherten personenbe- 
zogenen Daten. — Abschnitt 3.7 


Kriterium 9. Für jeden Übermittlungsvorgang ist eine Referenz auf die gespei- 
cherten personenbezogenen Daten, die übermittelt wurden, zu protokollieren. 
— Abschnitt 3.7.1 


Eine eigene Speicherung der übermittelten Daten ist nicht vorgesehen. Lediglich 
eine Referenz auf zu anderen Zwecken gespeicherte personenbezogene Daten 
ist erforderlich. 


Kriterium 10. Gesperrte personenbezogene Daten sind zu beauskunften, 
soweit sie nicht aufgrund einer Aufbewahrungsvorschrift gespeichert werden. 
— Abschnitt 3.7.1 


Kriterium 11. Der Ort der Speicherung (IT-System, Akte, Datenbank,...; 
besonders: Dateinamen, Struktur der Datenablage) personenbezogener Daten 
ist zu protokollieren und zu beauskunften. Die Protokolldaten sind so lange 
vorzuhalten, so lange die Speicherung anhält. — Abschnitt 3.7.1 


Kriterium 12. Der Ort der Verarbeitung (Prozess) personenbezogener Daten 
ist zu protokollieren und zu beauskunften, soweit der Ort der Verarbeitung 
Rückschlüsse auf persönliche oder sachliche Verhältnisse des Betroffenen 
zulässt. Die Protokolldaten sind so lange vorzuhalten, so lange die Verarbeitung 
anhält. + Abschnitt 3.7.1 
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Umfang der Protokollierung (Herkunft und Empfänger) 


Die Protokollierung von Herkunft und Empfänger wird ab Kriterium 13 
behandelt. Zunächst werden allgemeine Anforderungen gestellt, die unabhängig 
von den Kommunikationspartnern sind. 


Kriterium 13. Der Auskunftsanspruch umfasst die gespeicherten Herkunfts- 
angaben personenbezogener Daten. — Abschnitt 3.7 


Kriterium 14. Bei der internen Weitergabe sind Herkunftsangaben perso- 
nenbezogener Daten zu protokollieren. — Abschnitt 3.7.3 


Kriterium 15. Der Auskunftsanspruch umfasst die Empfänger personenbezo- 
gener Daten. Empfängerangaben sind zu protokollieren. — Abschnitt 3.7 


Empfänger sind alle Organisationseinheiten und alle dem Zweck nach ver- 
schiedene IT-Systeme innerhalb und außerhalb der verantwortlichen Stelle 
(— Abschnitt 3.7.2). Ein IT-System ist dann einer dezidiert anderen Stelle 
zuzuordnen, wenn ihm eine inhärent andere Rolle und Funktionalität in der 
Datenverarbeitung zukommt (— Abschnitt 3.7.2). 


Kriterium 16. Bei der Weitergabe gleichartiger Daten an gleichartige Emp- 
fänger zu gleichen Zwecken dürfen Empfänger, die Datensenken sind, im 
Protokoll und in der Auskunft kategorisiert werden (Betriebsgeheimnis). 
— Abschnitt 3.7.2 


Kriterium 17. Die Weitergabe ist auch bei nicht-automatisierter Verarbeitung 
zu protokollieren. — Abschnitt 3.7.2 
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Umfang der Protokollierung (Kommunikationsbeziehungen zu Dritten) 


Übermittlungen weisen in ihrer rechtlichen Bewertung Besonderheiten gegen- 
über der internen Weitergabe auf. Diese Besonderheiten sind in den nachfol- 
genden Kriterien erfasst. 


Kriterium 18. Jeder Übermittlung, ausgehend von der einen verantwortlichen 
Stelle, muss eine protokollierte Erhebung bei einer anderen verantwortlichen 
Stelle gegenüberstehen. — Abschnitt 3.7 


Kriterium 19. In der Auskunft über einen Empfänger, der Dritter ist, müssen 
alle Informationen, die die Übermittlung an den Empfänger referenzierbar 
machen (z. B. Zeitpunkt, Inhalt der Übermittlung, Gegenstelle beim Empfänger), 
enthalten sein. Diese Informationen sind zu protokollieren. + Abschnitt 3.7.2 


Kriterium 20. Beginn und Ende einer Veröffentlichung sind zu protokollieren 
und zu beauskunften. — Abschnitt 3.8.2 


Kriterium 21. Bei erst nach einer Authentifizierung abrufbaren personen- 
bezogenen Daten ist jeder Abruf zu protokollieren und zu beauskunften. 
— Abschnitt 3.8.2 


Kriterium 22. Protokolldaten über die Empfänger, die Dritte sind, dürfen 
erst dann gelöscht werden, wenn auch die Basisdaten bei Empfängern und 
Folgeempfängern gelöscht wurden. — Abschnitt 3.6 


Kriterium 23. Bei der Erhebung personenbezogener Daten zum Zweck der 
Übermittlung sind Protokolldaten über Empfänger, die Dritte sind, noch 
mindestens für ein Jahr nach der letzten Übermittlung zu speichern. — Ab- 
schnitt 3.6 


Kriterium 24. Herkunftsangaben bei der Erhebung sind für Daten, die 
zum Zweck der Übermittlung gespeichert werden, zu protokollieren. — Ab- 
schnitt 3.7.3 
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Kriterium 25. Bei listenmäßiger Übermittlung personenbezogener Daten zu 
Werbezwecken, sind Herkunftsangaben bei der Erhebung und Empfänger, die 
Dritte sind, noch mindestens für zwei Jahre nach der letzten Übermittlung zu 
speichern. — Abschnitt 3.6 


Kriterium 26. Herkunftsangaben bei der Erhebung dürfen erst gelöscht 
werden, nachdem eine Löschung der Empfänger, die Dritte sind, zulässig ist, 
falls solche existieren. > Abschnitt 3.4 


Umfang der Protokollierung (Zweck und Zeitpunkt) 


Die Zweckbindung ist eine eigenständige Anforderung des Datenschutzrechts, 
wirkt jedoch gemeinsam mit dem Auskunftsanspruch auch auf die Gestal- 
tung der Protokollierung. Wie die nachfolgenden Kriterien aufschlüsseln, sind 
Zweckbezüge und zeitliche Zusammenhänge Teil der erforderlichen Protokoll- 
informationen. 


Kriterium 27. Der Auskunftsanspruch umfasst den Zweck der Speicherung. 
Dieser ist zu protokollieren und zu beauskunften. —> Abschnitt 3.7 


Kriterium 28. Der Zweck muss nach einer Zweckänderung und in jedem 
Verwendungsschritt erkennbar bleiben. — Abschnitt 3.7.5 


Kriterium 29. Werden personenbezogene Daten zu mehreren unterschiedli- 
chen Zwecken verwendet, sind alle Zwecke zu protokollieren und zu beaus- 
kunften. — Abschnitt 3.7.5 


Kriterium 30. Der Zweck ist getrennt und unabhängig von der Art der Spei- 
cherung der personenbezogenen Daten zu protokollieren. — Abschnitt 3.7.5 


Kriterium 31. Der Zeitpunkt einer Erhebung oder Übermittlung personen- 
bezogener Daten ist zu protokollieren und zu beauskunften. — Abschnitt 3.7.1 


Kriterium 32. Der Zeitpunkt der Verarbeitung und Nutzung ist nur im 
Einzelfall auskunftspflichtig (Betriebsgeheimnis). — Abschnitt 3.7.1 
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Umfang der Protokollierung (Funktionalität und Prozesse) 


Die zwei nachfolgenden Kriterien leiten sich nicht allein aus dem Auskunfts- 
anspruch ab, sondern beruhen auch auf dem Prinzip der nicht-automatisierten 
Einzelentscheidung. Dieses Prinzip erweitert den Umfang des Auskunftsan- 
spruchs um funktionale Eigenschaften informationstechnischer Systeme. 


Kriterium 33. Die tragenden Funktionsprinzipien des logischen Aufbaus der 
automatisierten Verarbeitung personenbezogener Daten sind für IT-Systeme, 
auf die sich eine automatisierte Einzelentscheidung stützt, zu beauskunften. 
— Abschnitt 3.7.6 


Kriterium 34. Die für eine automatisierte Einzelentscheidung verwendeten 
personenbezogenen Daten sind zu beauskunften. — Abschnitt 3.7.6 


Benutzerschnittstelle 


Als Transparenzrecht ist für den Auskunftsanspruch die Interaktion des Be- 
troffenen mit dem Datenschutzauskunftssystem von großer Bedeutung. Nur 
wenn der Betroffene faktisch in der Lage ist die bereitgestellten Informationen 
zu durchdringen und zu verstehen, wird echte Transparenz hergestellt. Entspre- 
chend ergeben sich aus dem Auskunftsanspruch dezidierte Kriterien für die 
Gestaltung der Benutzerschnittstelle. 


Insbesondere darf der Weg eines Auskunftsersuchens nicht auf einen einzigen 
Kommunikationskanal beschränkt werden. Es muss beispielsweise möglich 
sein, dass der betriebliche Datenschutzbeauftragte die für die Auskunft er- 
forderlichen Informationen stellvertretend abruft und sie dem Betroffenen 
im Anschluss schriftlich mitteilt. Ebenso muss es möglich sein, dass ein 
Bevollmächtigter oder ein Erbe des Betroffenen Zugang zu den betreffenden 
Informationen erhält. 


Kriterium 35. Die Wahrnehmung des Auskunftsanspruchs erfordert ein 
aktives Handeln des Betroffenen. — Abschnitt 3.1 
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Kriterium 36. Ein stellvertretender Abruf der für die Auskunft erforderlichen 
Informationen muss möglich sein. — Abschnitt 3.4 und 3.3 


Kriterium 37. Wurden keine personenbezogenen Daten erhoben oder ver- 
wendet, ist dies zu beauskunften. — Abschnitt 3.7.7 


Kriterium 38. Die Benutzerschnittstelle muss so gestaltet sein, dass dem 
Betroffenen ein verständlicher — unter Verwendung klarer und einfacher 
Sprache — und einfacher Zugang zu den auskunftsrelevanten Informationen 
geboten wird. — Abschnitt 3.5 


Kriterium 39. Die verantwortliche Stelle darf keine formalen oder tech- 
nischen Bedingungen stellen, die der Betroffene zur Wahrnehmung seines 
Auskunftsanspruchs erfüllen muss. — Abschnitt 3.3 


4.3.2 Kriterien der übrigen Datenschutzanforderungen 


Die Kriterien aus den übrigen Datenschutzanforderungen ergänzen die direkt 
aus dem Auskunftsanspruch abgeleiteten Kriterien. 


Transparenzanforderungen, die neben dem Recht auf Auskunft stehen, beein- 
flussen den Entwurf eines Datenschutzauskunftssystem kaum. Sie beziehen sich 
auf Maßnahmen, die der Auskunft weitestgehend vorgelagert sind. Allerdings 
ergeben sich aus dem Auskunftsanspruch in Verbindung mit weiteren Anfor- 
derungen Kriterien für die Form der vorgelagerten Transparenzmaßnahmen. 
Vorgelagerte Transparenzmaßnahmen, wie beispielsweise die Benachrichti- 
gung, sind so zu gestalten, dass sie die Auskunft im Nachhinein ermöglichen. 


Organisatorische Vorgaben, wie die Etablierung eines Beauftragten für den 
Datenschutz (BfD), sind für ein technisches Datenschutzauskunftssystem 
unspezifisch und wurden deshalb in diesem Kriterienkatalog nicht erfasst. 
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Datenvermeidung 


Kriterium 40. Informationen über personenbezogene Daten, die für den 
Auskunftsanspruch nicht erforderlich sind, dürfen nicht protokolliert werden. 


Kriterium 41. Für den Auskunftsanspruch darf keine zusätzliche allgemeine 
Speicherung der personenbezogenen Basisdaten vorgenommen werden. 


Kriterium 42. Das Abrufen öffentlicher personenbezogener Daten durch einen 
Dritten ist nicht zu protokollieren und zu beauskunften. — Abschnitt 3.8.2 


Kriterium 43. Bei der Protokollierung darf kein Mitarbeiter-/Bearbeiterbezug 
hergestellt werden. 


Kriterium 44. Zeitangaben zu Verarbeitung und Speicherung dürfen nicht 
erhoben werden. 


Die Kriterien 43 und 44 tragen dem Mitarbeiterdatenschutz Rechnung. 


Datensparsamkeit 


Kriterium 45. Zum Zwecke der Auskunft gespeicherte, nicht mehr erforderli- 
che Informationen sind zu löschen. 


Kriterium 46. Protokolldaten über Verarbeitungsvorgänge sind zu löschen, 
sobald die Verarbeitung abgeschlossen ist. 


Kriterium 47. Protokolldaten über eine Speicherung sind zu löschen, sobald 
die Speicherung am entsprechenden Ort nicht mehr stattfindet. 


Anonyme und pseudonyme Dienste 


Kriterium 48. Das Auskunftsersuchen muss bei pseudonymen personenbezo- 
genen Daten über das Pseudonym möglich sein. — Abschnitt 3.4 
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Zugriffs-, Zugangs- und Weitergabekontrolle 


Kriterium 49. Die Identität des Auskunftsersuchenden ist gegen den eigenen 
Datenbestand zu prüfen. — Abschnitt 3.4 


Kriterium 50. Eine der Auskunft vorausgehende Benachrichtigung soll Schlüs- 
selkennungen (credentials) vergeben, die zur Authentifizierung bei der Aus- 
kunftserteilung verwendet werden können. — Abschnitt 3.1 


Kriterium 51. Das Datenschutzauskunftssystem sollte eine Auskunftsan- 
frage auf Grundlage unverwechselbarer und exklusiver Informationen über 
einen Erhebungsvorgang bei einem Dritten oder dem Betroffenen bzw. einem 
Weitergabevorgang an Dritte oder den Betroffenen zulassen. — Abschnitt 3.4 


Kriterium 52. Jeder Betroffene darf nur Zugriff auf Informationen zum 
Umgang mit personenbezogenen Daten erhalten, die sich aufihn selbst beziehen. 
— Abschnitt 3.4 


Kriterium 53. Beim Zugriff von Mitarbeitern der verantwortlichen Stelle auf 
zum Zwecke der Datenschutzauskunft gespeicherte personenbezogene Daten, 
ist das Vier-Augen-Prinzip zu wahren. 


Verfügbarkeitskontrolle 


Kriterium 54. Im Falle einer missbräuchlichen Verwendung des Auskunfts- 
rechts überwiegen die Interessen der verantwortlichen Stelle an einem unge- 
störten Betrieb und der Verhinderung einer Ausforschung. Die Auskunft darf 
dann blockiert werden. — Abschnitt 3.8.3 


Kriterium 55. Die Auskunft hat ohne schuldhaftes Zögern zu erfolgen." 
— Abschnitt 3.5 


! Gemäß Art. 12 Abs. 3 S. 1 DSGVO innerhalb eines Monats. 
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Kriterium 56. Die Auskunft hat jederzeit vollständig zu erfolgen. — Ab- 
schnitt 3.5 


Kriterium 57. Es muss verhindert werden, dass zur Auskunft notwendige 
Informationen unberechtigt gelöscht oder modifiziert werden. 


Revisionssichere Protokollierung 


Kriterium 58. Veränderungen an personenbezogenen Daten müssen nach- 
vollziehbar protokolliert werden. 


Kriterium 59. Die Integrität der Protokolldaten muss gewährleistet werden. 


Kriterium 60. Es muss sichergestellt werden, dass die Auskunft jederzeit 
korrekt ist. — Abschnitt 3.5 


Recht auf Datenübertragbarkeit 
Kriterium 61. Auf der Auskunftsplattform muss eine prominent platzierte 


Download-Möglichkeit in einem strukturierten, gängigen und maschinenles- 
baren Format zur Verfügung gestellt werden. — Abschnitt 3.5 


Einheitlicher Ansprechpartner 
Kriterium 62. Es muss eine zentrale Plattform geben, auf der das Auskunfts- 


ersuchen an die gesamte (verbundene) verantwortliche Stelle gestellt werden 
kann. 


Rechte auf Berichtigung, Löschung und Sperrung 


Kriterium 63. Die Auskunft muss die Wahrnehmung der Interventionsrechte 
Löschen, Sperren und Berichtigen ermöglichen. — Abschnitt 2.1.3 
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Zweckbestimmung 


Kriterium 64. Der konkrete Zweck der Verwendung muss zum Zeitpunkt der 
Erhebung festgelegt werden. — Abschnitt 3.7.5 


Der Zweck einer Speicherung ergibt sich aus den nachfolgend noch zulässigen 
Verarbeitungs- und Nutzungszwecken. 


Zweckbindung und Zwecktrennung 


Kriterium 65. Die für den Zweck der Auskunftserteilung gespeicherten Infor- 
mationen dürfen nur für diesen Zweck sowie für Zwecke der Datenschutzkon- 
trolle verwendet werden. 


Kriterium 66. Die im Rahmen des Auskunftsersuchens durch den Betroffenen 
übermittelten personenbezogenen Daten dürfen nur für die Bearbeitung des 
Auskunftsersuchens verwendet werden und sind für alle anderen Zwecke zu 
sperren. 


Aus Kriterium 66 ergibt sich noch keine Löschpflicht. Die Daten können also 
auch in Zukunft für die Bearbeitung von Auskunftsersuchen verwendet werden. 
Dies gilt nicht, falls der Betroffene dagegen Einspruch erhebt oder die weitere 
Speicherung seinen Interessen widersprechen würde. 


Kriterium 67. Die für den Zweck der Auskunftserteilung gespeicherten In- 
formationen sind für alle Zwecke außer der Auskunftserteilung zu sperren. 
— Abschnitt 3.6 


Kriterium 68. Die Datenhaltung der Protokolldaten muss von der Datenhal- 
tung der Basisdaten unabhängig sein. 


Kriterium 69. Die Verarbeitung der Protokolldaten muss getrennt von der 
Verarbeitung der Basisdaten erfolgen. 
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Organisatorische und technische Gewaltenteilung 


Kriterium 70. Zum Zweck der Auskunftserteilung erhobene Informationen 
diirfen zwischen Stellen nur dann ausgetauscht werden, wenn dies zur Errei- 
chung des Auskunftszwecks notwendig ist. — Abschnitt 4.2 


Kriterium 71. Protokolldaten dürfen nur dort gespeichert werden, wo sie 
anfallen (Datensubsidiarität). — Abschnitt 4.2 


Kriterium 72. Durch das Datenschutzauskunftssystem darf keine zusätzliche 
Zuordnung personenbezogener Daten zueinander sowie zum Betroffenen 
möglich sein, soweit dies für die Auskunft nicht zwingend erforderlich ist. 
— Abschnitt 4.2 


Kriterium 73. Die Verarbeitungswege und Weitergaben eines personenbe- 
zogenen Datums dürfen für eine Stelle, auch wenn sie an der Verarbeitung 
beteiligt ist, nicht durch das Datenschutzauskunftssystem nachvollziehbar 
gemacht werden. — Abschnitt 4.2 


4.4 Technische Anforderungen an ein 
Datenschutzauskunftssystem 


Die technischen Anforderungen für ein Datenschutzauskunftssystem prä- 
zisieren die rechtlichen Kriterien auf ihre technische Umsetzung hin und 
beschreiben konkrete Systemeigenschaften. Daraus folgt, dass nicht jedem 
rechtlichen Kriterium genau eine technische Anforderung entspricht. Manche 
Kriterien können technisch identisch beschrieben werden, andere erfordern 
mehrere technische Vorgaben. Bei jeder technischen Anforderung findet sich 
ein Verweis auf die rechtlichen Kriterien, die ihr zugrunde liegen. Die Ta- 
belle 4.2 gibt einen Überblick der Abbildung von rechtlichen Kriterien auf 
technische Anforderungen. Eine detaillierte Diskussion der Abbildung findet 
sich im Anhang B.3. 
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Der technischen Orientierung folgend, sind die technischen Anforderungen 
im Folgenden anders als die rechtlichen Kriterien nicht nach den datenschutz- 
rechtlichen Anforderungen sortiert, sondern nach funktionalen und nicht- 
funktionalen Anforderungen. Die weitere Unterteilung der Anforderungen hat 
rein informativen und keinen definitorischen Charakter. 


4.4.1 Funktionale Anforderungen 


Die funktionalen Anforderungen geben wieder, was ein Datenschutzauskunfts- 
system für den Betroffenen leisten soll. Kernfunktionalität des Datenschutz- 
auskunftssystems ist die Protokollierung des Umgangs mit personenbezogenen 
Daten. Deshalb machen die funktionalen Anforderungen Vorgaben an die 
Gestalt der Protokollinformationen, ihre Speicherung und Löschung. 


Allgemeine Systemanforderungen 


Anforderung 1. Systeme, die personenbezogene Daten verarbeiten oder 
speichern, müssen in der Lage sein, die stattfindenden Verarbeitungs-, Speicher- 
und Weitergabeereignisse in all ihren Teilsystemen zu erfassen. — Kriterium 1 


Anforderung 2. Die Erfassung der Verarbeitungs-, Speicher- und Weiterga- 
beereignisse muss auf der niedrigsten Abstraktionsschicht stattfinden, auf der 
das personenbezogene Datum noch semantisch erfassbar ist.’ — Kriterium 1 


Anforderung 3. Die Erfassung der Verarbeitungs-, Speicher- und Weiterga- 
beereignisse muss unabhängig von der Mitwirkung des Betroffenen möglich 
sein. — Kriterium 39 


Anforderung 4. Auf Grundlage der Protokollinformationen muss eine nach- 
trägliche globale Löschung, Sperrung und Berichtigung der personenbezogenen 
Daten möglich sein. — Kriterium 63 


! D.h., erkennbar ist, ob ein Datum ein personenbezogenes Datum ist. 
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Umfang der Protokollinformationen 


Anforderung 5. Informationen iiber personenbezogene Daten, die in keiner 
Anforderung aufgeführt sind und für die es auch keine anderen zwingen- 
den technischen Gründe gibt, dürfen nicht protokolliert werden. — Kriteri- 
en 40, 41, 43, 44 


Anforderung 6. Jeder Umgang mit personenbezogenen Daten muss, den 
nachfolgend formulierten Anforderungen entsprechend, protokolliert werden. 
— Kriterien 1, 58 


Anforderung 7. Das Protokoll zur Erhebung personenbezogener Daten muss 
folgendes umfassen: 


e die Quelle der Daten als global eindeutiger Protokollbestandteil, insbe- 
sondere deren Namen 


¢ den Zeitpunkt der Erhebung 
e die Kategorie der erhobenen Daten 
¢ die Organisationseinheit, in der das Datum erhoben wurde 
e das IT-System, auf dem das Datum erhoben wurde 
e die Zwecke der beabsichtigten Verwendung 
— Kriterien 1, 2, 3, 13, 24, 31, 64 
Anforderung 8. Bei der Erhebung ist ein Identifikator des Betroffenen, 


soweit vorhanden, zu protokollieren und mit den Protokollinformationen zu 
verknüpfen. — Kriterium 3 


Anforderung 9. Das Protokoll zur Übermittlung personenbezogener Daten 
muss folgendes umfassen: 


e die Senke der Daten als global eindeutiger Protokollbestandteil, insbe- 
sondere deren Namen 
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e den Zeitpunkt der Übermittlung 
e die Kategorie der übermittelten Daten 
e die Organisationseinheit, von der das Datum übermittelt wurde 
¢ das IT-System, von dem das Datum übermittelt wurde 
e die Zwecke der Übermittlung 
— Kriterien 1, 15, 19, 21, 28, 29, 31 
Anforderung 10. Das Protokoll zur Veröffentlichung personenbezogener 
Daten muss folgendes umfassen: 
e den Beginn der Veröffentlichung 
e das Ende der Veröffentlichung 
e die Kategorie der veröffentlichten Daten 
e die Organisationseinheit, von der das Datum veröffentlicht wurde 
¢ das IT-System, von dem das Datum veröffentlicht wurde 
e die Zwecke der Veröffentlichung 
— Kriterien 1, 20, 28, 29, 42 
Anforderung 11. Das Protokoll zur internen Weitergabe personenbezogener 
Daten muss folgendes umfassen: 
e den Zeitpunkt der Weitergabe 
e den Sender der Daten (Organisationseinheit und IT-System) 
¢ den Empfänger der Daten (Organisationseinheit und IT-System) 
e die Zwecke der Weitergabe 


— Kriterien 1, 14, 17, 28, 29, 32 
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Anforderung 12. Das Protokoll zur Verarbeitung personenbezogener Daten 
muss folgendes umfassen: 


¢ die Organisationseinheit, in der das Datum verarbeitet wurde 
e das IT-System, auf dem das Datum verarbeitet wurde 


e bei aussagekräftigen Spezialanwendungen: den Namen und den Typ der 
Anwendung 


e die Zwecke der Verarbeitung 


— Kriterien 1, 12, 28, 29, 32, 44 


Das IT-System ist nur zu protokollieren, sofern es als funktional eigene Stelle 
betrachtet werden kann. Name und Typ der Anwendung sind nur zu proto- 
kollieren, soweit der Ort der Verarbeitung Rückschlüsse auf persönliche oder 
sachliche Verhältnisse des Betroffenen zulässt. Ist die funktionale Abgrenzung 
unterschiedlicher Stellen a-priori nicht bekannt, ist so detailliert zu protokollie- 
ren, dass die Auskunft entsprechend der funktionalen Abgrenzung a-posteriori 
auf jeden Fall sichergestellt werden kann. 


Anforderung 13. Im Falle der automatisierten Einzelentscheidung sind die 
tragenden Funktionsprinzipien der Verarbeitung zu dokumentieren und mit 
den Verarbeitungsprotokollen zu verknüpfen. — Kriterium 33 


Anforderung 14. Gehen im Falle der automatisierten Einzelentscheidung 
mehrere personenbezogene Daten in einen Verarbeitungsvorgang mit ein, ist 
die gleichzeitige Verfügbarkeit dieser Daten im Prozess zu protokollieren. 
— Kriterium 34 


Anforderung 15. Das Protokoll zur Speicherung personenbezogener Daten 
muss folgendes umfassen: 


e die Organisationseinheit, in der das Datum gespeichert wurde 


e das IT-System, auf dem das Datum gespeichert wurde 
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e den Dateisystempfad zu dem Datum bzw. die Metadaten (Datenbank- 
name, Tabellenname, Attributname) der Datenbank, in der das Datum 
gespeichert ist 


e die Zwecke der Speicherung 
— Kriterien 1, 8, 11, 27, 28, 29 


Anforderung 16. Die durch den Fluss personenbezogener Daten entstehen- 
den wechselseitigen Beziehungen von Erhebung, Verarbeitung, Speicherung, 
interner Weitergabe, Übermittlung und Veröffentlichung müssen über Proto- 
kollgrenzen hinweg festgehalten werden und als durchgängige Personal-Data- 
Provenance nachvollziehbar sein. — Kriterium 1 


Anforderung 17. Jede protokollierte Übermittlung- und Veröffentlichung 
personenbezogener Daten muss, soweit verfügbar, mit einem Speicherort des 
Datums verknüpft sein. + Kriterium 9 


Anforderung 18. Die Zugriffe auf die Informationen zum Umgang mit seinen 
personenbezogenen Daten durch den Betroffenen müssen mit Zugriffszeitpunkt 
und übertragenen Informationen protokolliert werden. — Kriterium 5 


Speicherung der Protokolldaten 


Anforderung 19. Die Protokolldaten sind getrennt von den personenbezoge- 
nen Daten zu speichern und zu verarbeiten. — Kriterien 30, 68, 69 


Anforderung 20. Die Protokolldaten sind dort zu speichern, wo die proto- 
kollierten Ereignisse stattfinden. — Kriterium 71 


Anforderung 21. Die Protokolldaten werden nur zum Zeitpunkt einer Aus- 
kunftsanfrage von den speichernden Systemen abgerufen. — Kriterium 70 


Anforderung 22. Zum Abruf zwischengespeicherte Protokolldaten werden 
nach Ende der Auskunftsanfrage an zentraler Stelle wieder gelöscht. — Krite- 
rium 45 
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Speicherdauer und Löschregeln 


Anforderung 23. Das Datenschutzauskunftssystem speichert alle Protokoll- 
daten, solange keine Löschregel zutrifft. — Kriterien 6, 57 


Anforderung 24. Das Datenschutzauskunftssystem löscht Identifikatoren 
des Betroffenen, sobald diese auf keine Protokolldaten mehr verweisen. 
— Kriterium 7 


Anforderung 25. Das Datenschutzauskunftssystem löscht Informationen 
über die Erhebung eines personenbezogenen Datums, sobald keine anderen 
Informationen über den Umgang mit dem personenbezogenen Datum außer 
über die Erhebung mehr bestehen. — Kriterien 6, 25, 26 


Anforderung 26. Das Datenschutzauskunftssystem löscht Informationen über 
die Übermittlung eines personenbezogenen Datums, 


« sobald es von allen Empfängern die Bestätigung der Löschung des 
personenbezogenen Datums erhalten hat, 


e sofern die Übermittlung mindestens ein Jahr her ist, 


e sofern die Übermittlung mindestens zwei Jahre her ist, falls die Über- 
mittlung zum Zweck „Werbung“ erfolgte und 


e keine anderen Informationen über den Umgang mit dem personen- 
bezogenen Datum außer über die Erhebung und Übermittlung mehr 
bestehen. 


— Kriterien 6, 22, 23, 25 


Anforderung 27. Das Datenschutzauskunftssystem löscht Informationen über 
die interne Weitergabe eines personenbezogenen Datums, sobald keine Infor- 
mationen über Verarbeitung und Speicherung mehr bestehen. — Kriterium 6 
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Anforderung 28. Das Datenschutzauskunftssystem löscht Informationen über 
die Verarbeitung eines personenbezogenen Datums, sobald die Verarbeitung 
abgeschlossen ist. — Kriterien 6, 46 


Anforderung 29. Das Datenschutzauskunftssystem löscht Informationen 
über die Speicherung eines personenbezogenen Datums, sobald die perso- 
nenbezogenen Daten am entsprechenden Ort nicht mehr gespeichert werden. 
— Kriterien 6, 47 


4.4.2 Nicht-Funktionale Anforderungen 


Nicht-Funktionale Anforderungen haben bei Anwendungen, die personen- 
bezogene Daten verarbeiten, einen besonders hervorgehobenen Stellenwert. 
Für ein Datenschutzauskunftssystem stellen sie insbesondere die Berücksich- 
tigung der datenschutzrechtlichen Kriterien sicher, die sich nicht aus dem 
Auskunftsanspruch ergeben. 


IT-Sicherheitsfeatures sind qualitative Anforderungen an ein Datenschutzaus- 
kunftssystem und stehen stellvertretend für die Breite, in der unterschiedliche 
Datenschutzanforderungen abgedeckt werden, die nicht zur Grundfunktionalität 
des Auskunftsanspruchs beitragen. Die Charakteristiken der Benutzeroberfläche 
sind nicht funktional, da sie nicht vorgeben, was das Datenschutzauskunftssys- 
tem zu leisten hat, sondern wie die Ergebnisse der eigentlichen Systemlogik zu 
präsentieren sind. Dennoch leiten auch sie sich aus rechtlichen Kriterien ab. 


In der Kombination der funktionalen mit den nicht-funktionalen Anforderungen 
wird der Konflikt unterschiedlicher datenschutzrechtlicher Ziele auf technischer 
Ebene deutlich. Die besondere Herausforderung der späteren Spezifikation und 
Implementierung besteht darin, sich zum Teil widersprechenden Anforderungen 
gerecht zu werden. Namentlich die technischen Unverkettbarkeitsanforderungen 
und die durch die Protokollierung zu schaffende Transparenz erfordern eine 
gewissenhafte Abwägung. 
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Authentifikation, Autorisierung und Zugriffsrechte 


Anforderung 30. Ein aktives Einloggen des Betroffenen oder seines Stellver- 
treters auf der Auskunftsplattform ist fiir den Zugriff auf die Auskunftsinfor- 
mationen erforderlich. — Kriterium 35 


Anforderung 31. Das Datenschutzauskunftssystem muss Stellvertreterzu- 
griffsrechte ermöglichen. — Kriterium 36 


Anforderung 32. Beim Zugriff muss eine Identifikation über Pseudonym und 
ein gemeinsames Geheimnis, soweit vorhanden, möglich sein. — Kriterium 48 


Anforderung 33. Beim Zugriff muss eine Identifikation über vergebene 
Credentials, soweit vorhanden, möglich sein. + Kriterium 50 


Anforderung 34. Beim Zugriff muss eine Identifikation über eine bekannte 
Quelle mit Informationen über Art der Daten und des Informationsflusses, 
Zeitpunkt und Ursprung möglich sein, soweit kein Dritter diese Informationen 
wissen kann. — Kriterium 51 


Anforderung 35. Beim Zugriff soll eine Identifikation über eine bekannte 
Senke mit Informationen über Art der Daten und des Informationsflusses, 
Zeitpunkt und Adressat möglich sein, soweit kein Dritter diese Informationen 
wissen kann. — Kriterium 51 


Anforderung 36. Authentifizierungsinformationen (Gemeinsame Geheimnis- 
se, Schliisselkennungen, elektronischer Personalausweis (nPA) oder exklusives 
Wissen) miissen vor dem Zugriff tiberpriift werden und giiltig sowie korrekt 
sein. — Kriterium 49 


Anforderung 37. Authentifizierungsinformationen miissen an die Autorisie- 
rung fiir den Datenbestand des entsprechenden Betroffenen (und keine weiteren 
Daten) geknüpft werden. — Kriterium 52 
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Anforderung 38. Beim Stellvertreterzugriff miissen sich zwei voneinander 
unabhängige Personen (z. B. Kundenbetreuer und Datenschutzbeauftragter) 
gemeinsam beim Datenschutzauskunftssystem authentifizieren, um für den 
Zugriff auf die Auskunftsinformationen autorisiert zu sein. — Kriterium 53 


Anforderung 39. Die Protokolldaten dürfen nur vom Datenschutzauskunfts- 
system selbst, entsprechend den funktionalen Anforderungen, modifiziert wer- 
den. Der schreibende Zugriff muss darüber hinaus unterbunden werden. 
— Kriterien 57, 59 


Anforderung 40. Auf die Protokolldaten darf nur der Betroffene (oder sein 
Stellvertreter) im Rahmen einer Auskunftsanfrage zugreifen. Der lesende Zugriff 
muss darüber hinaus unterbunden werden. — Kriterien 65, 66, 67 


Anforderung 41. Das Datenschutzauskunftssystem darf nur im Rahmen 
des technisch erforderlichen und soweit möglich nur lokal lesend auf die 
Protokolldaten zugreifen. — Kriterium 65 


Unverkettbarkeit 


Anforderung 42. Systeme dürfen durch die bei ihnen gespeicherten Proto- 
kolldaten kein neues Wissen darüber gewinnen, auf welchen Systemen ein 
bestimmtes personenbezogenes Datum verarbeitet und/oder gespeichert wurde. 
— Kriterium 73 


Anforderung 43. Systeme dürfen durch die bei ihnen gespeicherten Proto- 
kolldaten kein neues Wissen darüber gewinnen, welche Systeme ein bestimmtes 
personenbezogenes Datum an welche anderen Systeme weitergegeben haben. 
— Kriterium 73 


Anforderung 44. Systeme dürfen durch die bei ihnen gespeicherten Protokoll- 
daten kein neues Wissen darüber gewinnen, ob zwei personenbezogene Daten 
einen Personenbezug zum selben Betroffenen aufweisen. — Kriterium 72 
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Anforderung 45. Systeme diirfen durch die bei ihnen gespeicherten Protokoll- 
daten kein neues Wissen dariiber gewinnen, ob ein personenbezogenes Datum 
einen Personenbezug zu einem bestimmten Betroffenen aufweist. — Kriteri- 
um 72 


Die technischen Anforderungen an die Unverkettbarkeit werden in Kapitel 9 
formalisiert und messbar gemacht. 


Auskunftsplattform - Aussehen, Handhabung, Benutzbarkeit 


Anforderung 46. Der Zugriff auf die Benutzeroberfläche muss für jeden 
Betroffenen mit Standardsoftware (z. B. Webbrowser) möglich sein. Es darf 
keine Installation clientseitiger Spezialsoftware vorausgesetzt werden. — Kri- 
terium 39 


Anforderung 47. Über die Benutzeroberfläche muss für jeden Betroffenen 
ein Zugriff auf alle personenbezogenen Daten, inklusive der für die Auskunft 
ergänzend gespeicherten Informationen, möglich sein. — Kriterium 62 


Anforderung 48. Die Benutzeroberfläche muss eine konsistente, durchgängi- 
ge Wahrnehmung aller interaktiven Betroffenenrechte (Löschung, Sperrung, 
Berichtigung) ermöglichen. — Kriterium 63 


Anforderung 49. Jedes auf der Benutzeroberfläche dargestellte Datum muss 
eine direkte Interaktionsmöglichkeit im Rahmen der Betroffenenrechte anbieten. 
— Kriterium 63 


Anforderung 50. Die vorangegangenen erteilten Auskünfte müssen auf der 
Benutzeroberfläche der Auskunftsplattform sichtbar sein. — Kriterium 5 


Anforderung 51. Auf der Benutzeroberfläche muss klar dargestellt wer- 


den, falls keine personenbezogenen Daten erhoben oder verwendet wurden. 
— Kriterium 37 


131 


4 Datenschutzrechtliche Anforderungen an ein Datenschutzauskunftssystem 


Anforderung 52. Es müssen Selektionsméglichkeiten für die Protokollinfor- 
mationen nach Datenkategorie, Zweck, Herkunft und Empfdnger vorhanden 
sein. — Kriterium 38 


Anforderung 53. Die Protokolldaten müssen in einem strukturierten, gängi- 
gen und maschinenlesbaren Format als Ganzes herunterladbar sein. — Krite- 
rium 61 


Zuverlässigkeit und Korrektheit 


Anforderung 54. Die Protokollierung muss ab dem Zeitpunkt der Erhebung 
ohne Unterbrechung erfolgen. — Kriterium 2 


Anforderung 55. Die Auskunft muss die Protokollinformationen exakt und 
vollständig wiedergeben. — Kriterien 2, 56, 60 


Anforderung 56. Die Protokolldaten müssen bei mobilen IT-Systemen' und 
IT-Systemen mit niedriger Verfügbarkeit redundant gespeichert werden. — Kri- 
terium 56 


Anforderung 57. Bei Angriffen auf die Auskunftsplattform oder Missbrauch 


derselben darf der Zugang zur Plattform vorübergehend deaktiviert werden. 
— Kriterium 54 


Flexibilität und Übertragbarkeit 


Anforderung 58. Die Schnittstelle des Datenschutzauskunftssystems muss 
dokumentiert und standardisiert sein. — Kriterien 18, 62 


! Beispielsweise Laptops oder Smartphones. 
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4.5 Zwischenfazit 


Performance und Skalierbarkeit 


Anforderung 59. Eine Auskunft muss innerhalb der üblichen Ladezeiten 
einer Webseite mit aktiven oder multimedialen Inhalten bereitgestellt werden. 
— Kriterium 55 


4.5 Zwischenfazit 


Dieses Kapitel hat zwei Resultate hervorgebracht: Das Modell zur Ableitung 
rechtlicher Anforderungen EVAL und die Anwendung dieses Modells auf 
das Recht auf Auskunft bzw. den Einsatz eines Datenschutzauskunftssystems. 
Konstruktionsziel 1 ist damit erreicht. 


EVAL ist dem bisher bestehenden Modell KORA dahingehend überlegen, dass 
eine klarere Systematisierung der rechtlichen Anforderungsableitung erfolgt 
und die Ableitung nicht auf rechtlicher Ebene stehen bleibt, sondern der Pfad 
bis zur tatsächlichen Implementierung vorgezeichnet ist. 


Die Aufstellung rechtlicher Kriterien für ein Datenschutzauskunftssystem baut 
auf den Erkenntnissen aus Kapitel 3 auf. Aus rechtlichen Kriterien ergeben 
sich technische Anforderungen, die auf die Implementierung des Datenschutz- 
auskunftssystems angewandt werden können. 
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4 Datenschutzrechtliche Anforderungen an ein Datenschutzauskunftssystem 


Tabelle 4.2: Ableitung technischer Anforderungen aus rechtlichen Kriterien 


Rechtliche Technische Rechtliche Technische 


Kriterien Anforderungen Kriterien Anforderungen 
1 1, 2, 6, 7, 9, 10, 11, 12, 15, 16 38 52 

2 7,54, 55 39 3,46 
3 7,8 40 5 

4 41 5 

5 18, 50 42 10 

6 23, 25, 26, 27, 28, 29 43 5 

7 24 44 5,12 
8 15 45 22 

9 17 46 28 

10 47 29 

11 15 48 32 

12 12 49 36 

13 i 50 33 

14 11 51 34, 35 
19 9 52 37 

16 53 38 

17 11 54 57 

18 58 55 59 

19 9 56 55, 56 
20 10 34 23, 39 
21 9 58 6 

22 26 59 39 

23 26 60 55 

24 7 61 53 

25 25, 26 62 47,58 
26 25 63 4, 48, 49 
27 15 64 7 

28 9,10, 11, 12, 15 65 40, 41 
29 9,10, 11, 12, 15 66 40 

30 19 67 40 

31 7,9 68 19 

32 11,12 69 19 

33 13 70 21 

34 14 71 20 

35 30 72 44, 45 
36 31 73 42, 43 
37 51 
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Teil II 


Personal-Data-Provenance und 
Data-Usage-Control 
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5 Usage-Control & 
Provenance-Tracking: Einführung 
und Architektur 


Aus den in den vorangegangen Kapiteln abgeleiteten Anforderungen ergibt 
sich, dass für ein Datenschutzauskunftssystem eine einfache Protokollierung 
von Ereignissen in IT-Systemen nicht ausreichend ist. Das Recht auf Auskunft 
fordert eine durchgängige Historie (Kriterium 1), sprich die technische Reali- 
sierung einer Personal-Data-Provenance (Anforderung 16), für den Umgang 
mit jedem personenbezogen Datum. Diese Datenzentriertheit, die auch die 
Berücksichtigung weiterer datenbezogener Anforderungen erlaubt, findet sich 
in bisherigen Ansätzen zur technischen Realisierung der Datenschutzauskunft 
nicht in ausreichendem Maße. 


Das Recht auf Auskunft steht nicht allein, sondern neben weiteren Betroffe- 
nenrechten (Kriterium 4). Um die Wahrnehmung dieser weiteren Rechte zu 
ermöglichen, ist eine Verbindung von Personal-Data-Provenance mit Data- 
Usage-Control erforderlich. Usage-Control und Provenance-Tracking ergänzen 
sich hinsichtlich der Anforderungen des Rechts auf Auskunft. ! 


Dieses Kapitel gibt einen Überblick über die Entwicklung in den Forschungs- 
bereichen Data-Provenance und Usage-Control sowie den noch bestehenden 
Defiziten im Hinblick auf eine integrierte Architektur für ein Datenschutz- 
auskunftssystem. Anhand der Anforderungen aus Kapitel 4.4 wird eine ge- 
meinsame Architektur für Data-Provenance und Usage-Control hergeleitet und 
beschrieben. Die Rollen der einzelnen Komponenten werden erläutert und ihre 
Schnittstellen spezifiziert. 


l Bier 2013b. 
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5.1 Personal-Data-Provenance: Eine 
Einführung 


Provenance (auch Lineage oder Pedigree) ist ein Begriff, unter dem die 
Sichtbarmachung der Historie eines Datums verstanden wird.! Data-Provenance 
ist die dokumentierte Ableitungshistorie eines Datums, ausgehend von seiner 
ursprünglichen Quelle.” Data-Provenance gibt Auskunft über die Herkunft 
von Daten sowie über die Erzeugung von Daten aus anderen Daten. Ein 
technisches System, das solche Fragestellungen beantworten kann, ist ein 
Provenance-System. 


Eine Provenance-Infrastruktur muss drei wesentliche Komponenten bereitstel- 
len (Abbildung 5.1): Einen Erhebungsmechanismus, um den Umgang mit Daten 
aufzuzeichnen (Provenance-Collection), die Infrastruktur zur Speicherung der 
Provenance-Daten (Provenance-Storage) und Funktionen, um die Daten im 
Nachgang adäquat nutzbar zu machen (Provenance-Dissemination).* In der 
Vergangenheit wurden Provenance-Systeme für das wissenschaftliche Rech- 
nen,* Betriebssysteme, Dateisysteme,° Geschiiftsprozesse’ und ausgewählte 
Anwendungen® entwickelt. 


Anwendungsgebiete sind die Reproduzierbarkeit von wissenschaftlichen Er- 
gebnissen, die Vertrauenswürdigkeit von Sensordaten, die Auditierung von 
Systemen und Prozessen, die Vorhersage zukünftiger Geschäftsprozesse, Ac- 
countability und Compliance der Datenverarbeitung in stark regulierten Bran- 
chen und die Erkennung von Beziehungen und Gemeinschaften in sozialen 


1 Simmhan/Plale/Gannon 2005. 

2 Buneman/Khanna/Tan 2001; Miles et al. 2005; Simmhan/Plale/Gannon 2005. 
3 Freire et al. 2008; Lakshmanan et al. 2011 

4 Bose/Frew 2005; Freire et al. 2008; Moreau/Groth et al. 2008. 

5 Gehani/Tariq 2012. 

6 Gehani/Lindqvist 2007; Holland et al. 2008; Sultana/Bertino 2013. 

7 Bechini et al. 2008; Curbera et al. 2008; Gadelha Jr./Mattoso 2008. 

8 Fonseca et al. 2007; Muniswamy-Reddy et al. 2009; Tarig/Ali/Gehani 2012. 
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Provenance Provenance ' Provenance 


Collection Storage | Dissemination 


Abbildung 5.1: Komponenten einer Data-Provenance-Infrastruktur 


Netzwerken.' Überall dort müssen bestehende Systeme provenancefähig ge- 
macht werden, so dass sie Provenance-Informationen publizieren können. 
Außerdem muss eine Speicherinfrastruktur für Provenance etabliert werden, 
die die Administration, die Abfrage (Querying) und das Schlussfolgern (Rea- 
soning) von und aus Provenance-Informationen zulässt. 


Data-Provenance hat drei Dimensionen, die in Provenance-Modellen abgedeckt 
werden müssen (Abbildung 5.2): Informationsfluss-Provenance, Funktions- 
Provenance? und Kontext-Provenance. Provenance kann sich auf einen Prozess 
oder auf ein Datum beziehen. Personal-Data-Provenance ist datenzentriert. 


Jede Dimension von Provenance muss sich gemäß der Anforderungen aus 
Kapitel 4 auch in Personal-Data-Provenance wiederfinden. Gemäß der An- 
forderungen 7, 9, 11 und 16 muss die Informationsfluss-Provenance perso- 
nenbezogener Daten, inklusive der Quellen und Senken, gesammelt werden. 
Funktions-Provenance ist für den Spezialfall automatisierter Einzelentschei- 
dungen mitzuberücksichtigen (Anforderungen 13 und 14). In wenigen anderen 
Fällen sind die Ein- und Ausgabeparameter der Verarbeitung zu erfassen 
(Anforderung 12). Kontext-Provenance findet sich in Form von Zweckbindung 
und Zeitangaben (Anforderungen 7, 9-12, 14, 15 und 18) in der Personal-Data- 
Provenance. 


1 Moreau/Groth et al. 2008; Lakshmanan et al. 2011. 
? Funktion im Sinne der internen Abbildungsfunktionen eines Programms, die aus einer Menge 
von Eingabewerten einen Ausgabewert (Resultat) bestimmt. 
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Informationsfluss if 


© Funktion f - > + - >@ 


Kontext c 


Abbildung 5.2: Data-Provenance-Dimensionen 


Eine standardisiertes Daten- und Austauschformat für Provenance im wis- 
senschaftlichen Rechnen wurde mit dem Open Provenance Model (OPM) 
eingeführt. Dessen Spezifikation in der Version 1.1 wurde im Jahr 2011 
veröffentlicht. ! 


Personal-Data-Provenance wurde in der jüngeren Literatur eingeführt. Aldeco- 
Pérez und Moreau schlagen vor, Provenance für die Auditierung der Verwendung 
personenbezogener Daten heranzuziehen.” Herkenhöhner et al. stellen eine 
Architektur und ein Nachrichtenformat vor, um die für das Recht auf Auskunft 
erforderliche Provenance in organisationsübergreifenden Webservices automa- 
tisiert zu sammeln und dem Betroffenen zur Verfügung zu stellen.? Pulls et al. 
stellen ein Schema, Insynd, vor, um Personal-Data-Provenance zu sammeln, 
ohne die Verknüpfungen zwischen den einzelnen Logs zu offenbaren.* 


Die Sicherheit von Data-Provenance im Allgemeinen wurde in der Literatur 
bereits intensiv diskutiert. Konzepte für die Suche in verschlüsselter Data- 
Provenance finden sich bei Asghar et al.” Davidson et al. diskutieren die 
Bewahrung von Anonymität in Queries auf Data-Provenance.® Access-Control 


! Moreau/Clifford et al. 2011. 

2 Aldeco Pérez/Moreau 2008. 

3 Herkenhöner et al. 2010. 

4 Pulls/Peeters/Wouters 2013; Pulls/Peeters 2015. 
5 Asghar et al. 2012. 

6 Davidson et al. 2011. 
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fiir Provenance wurde als XACML-Erweiterung, ! in ODRL,? sowie als ei- 
genständiges Konzept? umgesetzt. Butin, Chicote und Le Métayer definieren 
Richtlinien für das Log-Design für Accountability-Frameworks.* Diese For- 
schungsgegenstände und Lösungsvorschläge sind orthogonal zum Thema dieser 
Arbeit. Ihre Anwendung auf das Datenschutzauskunftssystem kann dessen 
Sicherheit und damit auch den Erfüllungsgrad der nicht-funktionalen Anforde- 
rungen verbessern. Im Rahmen dieser Arbeit wird aufgrund der existierenden 
Forschung angenommen, dass die Personal-Data-Provenance sicher gespeichert 
ist und die Zugriffsrechte entsprechend des Nutzungszwecks der Provenance 
formuliert und durchgesetzt werden. 


5.2 Usage-Control: Beschreibungssprachen und 
Durchsetzung 


Nutzungskontrolle (engl. Usage Control (UC)) bestimmt, unter welchen Um- 
ständen Zugriff auf Daten gewährt wird und wie nachfolgend mit den Daten um- 
gegangen werden darf. UC kann auch als eine Erweiterung von Access-Control 
über den Zugriffszeitpunkt hinaus betrachtet werden. Die bisherige Forschung 
im Themenbereich? hat unterschiedliche Aspekte von Usage-Control beleuch- 
tet. Im Laufe der Zeit sind eine Vielzahl von Policy-Sprachen entstanden: 
UCON® und UCON zc,’ sowie eine Erweiterung der EXtensible Access 
Control Markup Language (XACML) für UCON-Policies,® die Open Digital 
Rights Language (ODRL)? für Digital Rights Management (DRM) sowie die 


! Cadenhead et al. 2011. 

2 Grunwell/Gajanayake/Sahama 2015. 

3 Ni/Bertino/Sandhu 2009. 

4 Butin/Chicote/Metayer 2013. 

5 Lazouski/Martinelli/Mori 2010; Pretschner/Hilty/Basin 2006; Pretschner/Hilty/Schutz et al. 
2008. 

6 Park/Sandhu 2002. 

7 Park/Sandhu 2004; X. Zhang et al. 2004. 

8 Lazouski/Martinelli/Mori 2012. 

° Tannella 2004; https://www.w3.org/community/odrl. 
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Obligation Specification Language (OSL),! die in ODRL transformierbar ist.” 
Das in dieser Arbeit vorgestellte Datenschutzauskunftssystem setzt auf der 
OSL auf. Grundsätzlich ist jedoch auch jede andere Beschreibungssprache mit 
gleicher Mächtigkeit anwendbar. 


Die Durchsetzung von Policies wurde für Java, die OpenNebula Cloud- 
Lösung,* Android,’ Firefox,° Thunderbird,’ Microsoft Windows, ® OpenBSD,’ 
X11'° und die intelligente Videoüberwachung!! sowie über Systemgrenzen 
hinweg ! umgesetzt. Die Erweiterung um zustandsbasierte Policies und das 
dafür notwendige Informationsfluss-Tracking'? haben das Tor zu einer Verbin- 
dung von Usage-Control und Provenance-Tracking aufgestoßen. Ein Vorteil 
der in diesem Kapitel vorgestellten integrierten Architektur ist die Wiederver- 
wendbarkeit dieser bestehenden Implementierungen zur Nutzungskontrolle. 
Die in dieser Arbeit verwendet Beispiele greifen insbesondere auf die exis- 
tierenden Usage-Control-Komponenten für Microsoft Windows zurück. Für 
das Shopsystem Shopware'* und weitere kleine Applikationen wurden eigene 
Lösungen implementiert. 


Parallel dazu wurden Beschreibungssprachen für den Datenschutz entwickelt, 
die dazu geeignet sind, die Präferenzen von Nutzern zur Datenverarbeitung 
in Unternehmen formalisierbar und die Bedingungen der Datenverarbeitung 


! Hilty et al. 2007. 

2 Hilty et al. 2007. 

3 Fromm/Kelbert/Pretschner 2013. 

4 Lazouski/Mancini et al. 2014. 

5 Feth/Pretschner 2012; Rasthofer et al. 2014 
6 Kumari/Pretschner et al. 2011. 

7 Lörscher 2012. 

8 Wüchner/Pretschner 2012. 

9 Harvan/Pretschner 2009. 
!0Pretschner/Biichler et al. 2009. 

1l Birnstill/Pretschner 2013. 

!2Basin et al. 2013; Kelbert/Pretschner 2013. 
13Harvan/Pretschner 2009; Pretschner/Lovat/Büchler 2011. 
'4https://de.shopware.com. 
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aushandelbar zu machen. Das Projekt Platform for Privacy Preferences (P3P),! 
das Endnutzertool Privacy Bird? und die Beschreibungssprachen Enterprise 
Privacy Authorization Language (EPAL),* S4P,* und A-PPL,? ebenfalls eine 
Erweiterung von XACML, sind Repräsentanten dieser Strömung. A-PPL 
wird im Projekt A4Cloud eingesetzt. Die aktuelle Spezifikation erlaubt die 
Deklaration einer Aktion ActionLog, um die Protokollierung des Umgangs 
mit personenbezogenen Daten und den Umfang des Protokolls festzuschreiben. 


Diese Arbeit stellt keine neue Beschreibungssprache vor. Es werden bestehen- 
de Forschungsergebnisse aus zwei Griinden wiederverwendet: Erstens, um 
Provenance-Tracking tiber eine Tracking-Policy fiir ein bestimmtes Datum zu 
aktivieren.° Zweitens, um die Durchsetzung der über das Recht auf Auskunft 
hinausgehenden Betroffenenrechte, wie Löschen und Sperren, sicherzustel- 
len. Der Beitrag dieser Arbeit ist die Integration von Usage-Control und 
Provenance-Tracking in einer gemeinsamen Architektur, um das Recht auf 
Auskunft sowie die übrigen Betroffenenrechte gemeinsam zu gewährleis- 
ten (Anforderung 4). Weitere Beiträge sind in den nachfolgenden Kapiteln 
im Themenfeld Informationsfluss-Tracking für Personal-Data-Provenance zu 
finden. 


Im Hinblick auf OSL haben Usage-Control-Policies eine Struktur, die dem 
Schema „Event - Condition — Action (ECA)“ folgt.’ Ein Event (Ereignis, siehe 
Kapitel 6.1) ist der Auslöser für die Anwendung der Policy. Die Condition 
(Bedingung) beschreibt die Voraussetzungen, die erfüllt sein müssen, damit 
der dritte Teil der Policy greift. Bedingungen können zeitlicher oder kardinaler 
Art sein oder von Umweltvariablen abhängen. Action ist die eigentliche Folge, 
falls die Policy greift. Vier verschiedene Mechanismen sind möglich: Eine 


1 https://www.w3.org/P3P. 

? Lorrie Faith Cranor/Guduru/Arjula 2006. 

3 https://www.w3.org/Submission/2003/SUBM-EPAL-20031110. 

4 Becker/Malkis/Bussard 2010. 

5 Fernandez-Gago et al. 2015. 

6 Wird das integrierte System einzig für den Zweck der Auskunft betrieben, kann das Provenance- 
Tracking global für alle personenbezogenen Daten aktiviert werden. Eine Tracking-Policy ist 
dann nicht erforderlich. 

7 Hilty et al. 2007. 
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Unterbindung des Events (Inhibit), eine zeitliche Verschiebung des Events 
(Delay), eine Modifikation des Events (Modify) oder die Ausführung einer 
Aktion zusätzlich zum Event (Execute).! Die Aufzeichnung der Provenance ist 
ein typischer Fall eines Execute-Mechanismus. Ein Sperren personenbezogener 
Daten lässt sich über einen Inhibit-Mechanismus realisieren. 


Für die Auswertung und Durchsetzung der Policies sind die im folgenden 
Abschnitt vorgestellten Komponenten verantwortlich. 


5.3 Integrierte generische Architektur für 
Usage-Control & Provenance-Tracking 


Die Architekturen für Usage-Control und Provenance-Tracking sind ähnlich. 
Systeme für beide Konzepte benötigen eine Komponente, die Ereignisse abfängt 
und eine Komponente, die den Zustand der Umgebung beziehungsweise die 
Provenance speichert. Usage-Control und Provenance-Tracking ergänzen sich 
im Hinblick auf die Umsetzung und Durchsetzung der Betroffenenrechte.? 
Das Recht auf Auskunft setzt Data-Provenance voraus. Die Sicherstellung, 
dass die Provenance gesammelt wird, und die Durchsetzung der übrigen 
Betroffenenrechte erfordern Usage-Control. 


Die grobe Struktur einer Provenance-Architektur wurde bereits in Abschnitt 5.1 
(Abbildung 5.1) vorgestellt. Die Grundstruktur der Usage-Control-Architektur 
findet sich bereits in RFC 2748,3 RFC 4261 (Common Open Policy Service 
(COPS) Over Transport Layer Security (TLS))* sowie in RFC 2904 (AAA 
Authorization Framework)? und hat sich im Rahmen von XACML etabliert.® 


! Pretschner/Hilty/Basin et al. 2008. 

? Bereits vorgestellt und diskutiert in Bier 2013b. 

3 https://tools.ietf.org/html/rfe2748; PEP & PDP. 

4 https://tools.ietf.org/html/rfc426 1. 

5 https://tools.ietf.org/html/rfc2904; PEP, PDP, PIP & PRP. 

6 http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html; PEP, PDP, PIP & PAP. 
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Abbildung 5.3: Logische Usage-Control- und Provenance-Architektur 
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5.3.1 Architektur 


Die integrierte generische Architektur umfasst alle fiir Usage-Control und 
Provenance-Tracking erforderlichen Komponenten. Diese werden nachfolgend 
motiviert und erläutert. Das Zusammenspiel der Komponenten wird anhand 
von Abbildung 5.3 deutlich gemacht. 


Der Policy Enforcement Point (PEP) ist die Schnittstelle zwischen der Ar- 
chitektur und ihrer Umwelt. Für jede Abstraktionsschicht, die der Nutzungskon- 
trolle unterworfen werden soll oder in der der Umgang mit personenbezogenen 
Daten nachvollzogen werden soll, muss ein PEP eingebunden werden (Anfor- 
derungen 1 und 2). Abstraktionsschichten sind beispielsweise Betriebssysteme, 
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Fenstermanager, Dateisysteme, Datenbanken, Anwendungen und Infrastruk- 
turkomponenten wie Firewalls und Workflow-Engines. Der PEP fängt die 
in seiner Abstraktionsschicht stattfindenden Ereignisse ab und leitet sie an 
den PDP und den PIP weiter. Das Ereignis wird zunächst pausiert. Abhängig 
von der Entscheidung des PDP wird das Ereignis zugelassen, unterbunden 
oder entsprechend der Vorgaben des PDP modifiziert (siehe Abschnitt 5.2). 
Ein PEP, der Ereignisse nicht unterbindet oder modifiziert, wird auch als 
„Event-Listener“ bezeichnet. 


Jeder PEP kennt die Semantik der auf seiner Abstraktionsschicht stattfindenden 
Ereignisse, insbesondere der daraus resultierenden Informationsflüsse (siehe 
Kapitel 6.2). Informationsflüsse können auch zwischen Abstraktionsschichten 
und IT-Systemen stattfinden. Dieser Aspekt wird in Kapitel 8.1 gesondert 
behandelt. 


Der Policy Decision Point (PDP) hält den Zustand aller Usage-Control- 
Policies, insbesondere deren kardinale und zeitliche Bedingungen, vor. Wird 
dem PDP vom PEP ein Ereignis mitgeteilt, entscheidet er anhand des Zustands 
und weiterer Informationen, die der PDP vom PIP erhält, ob das Ereignis 
stattfinden darf, ob es modifiziert oder unterbunden werden muss oder ob das 
Ereignis weitere Aktionen nach sich zieht. Ein PDP ist für eine lokale Domäne, 
im Regelfall ein IT-System, verantwortlich. 


Policy Information Point (PIP) und Provenance Storage Point (ProSP). 
Ein PIP hält weitere Informationen vor, die der PDP zur Entscheidungsfindung 
benötigt. 


Ein besonderer PIP, der Informationsfluss-PIP, bildet gemeinsam mit dem 
ProSP den „Information-Flow-Tracking & Provenance-Storage“-Teil der Ar- 
chitektur.! Der Informationsfluss-PIP hält den Zustand des Informationsfluss- 
modells (Kapitel 6) vor. Bei jedem Ereignis, das auf eine Policy passt, die 
informationsflussabhängig ist, fragt der PDP den PIP an. Der PIP berechnet 


! Im Rest der Arbeit wird mit dem Begriff PIP immer der Informationsfluss-PIP bezeichnet. 


146 


5.3 Integrierte generische Architektur fiir UC & Provenance-Tracking 


den durch das Ereignis entstehenden Zustand vor und informiert den PDP 
auf dieser Basis. Wird ein Ereignis zugelassen, wird der PIP darüber vom 
PEP informiert und aktualisiert seinen internen Zustand dauerhaft. Der PIP 
erhält die Semantik zur Interpretation der Ereignisse vom PEP. Dazu registriert 
sich der PEP beim PIP, sobald er gemeinsam mit seiner Abstraktionsschicht 
gestartet wurde. 


Der ProSP baut die Personal-Data-Provenance auf und speichert sie getrennt 
von den personenbezogenen Daten, für die die Provenance erzeugt wird (An- 
forderung 19). Personal-Data-Provenance wird also, Anforderung 20 folgend, 
dezentral abgelegt und für den Betroffenen zum Abruf bereitgehalten. Imple- 
mentierungstechnisch können Informationsfluss-PIP und ProSP gemeinsam 
realisiert werden. Um beide Komponenten getrennt einsetzen zu können, 
beispielsweise, wenn kein Provenance-Tracking benötigt wird, werden der 
Informationsfluss-PIP und der ProSP nur lose gekoppelt. PIP und ProSP sind 
wie der PDP für eine bestimmte lokale Domäne verantwortlich. 


Ein Policy Execution Point (PXP) wird vom PDP aufgerufen, sofern eine 
Policy gemeinsam mit einem Ereignis die Ausführung weiterer Aktionen 
erfordert. Ein PXP kann beispielsweise dafür verantwortlich sein, den Benutzer 
über die Entscheidung des PDP zu benachrichtigen. 


Der Policy Management Point (PMP) ist, wie der Namen sagt, für die 
Verwaltung der Policies zuständig. Er nimmt neue Policy-Templates! entgegen, 
instanziiert diese und fordert den PDP dazu auf, eine Policy zu laden und 
anzuwenden, wenn dies von administrativer Seite gewünscht wird. Werden 
Policies systemübergreifend ein- und durchgesetzt, ist der PMP dafür zuständig, 
die Policy auf andere Systeme zu übertragen, bevor ein Datenfluss auf diese 
Systeme stattfindet. Policies und Policy-Templates werden im Policy Retrieval 
Point (PRP) gespeichert. 


! Ein Policy-Template ist eine Policy, in der bestimmte Parameter, beispielsweise das referenzierte 
Datum, noch offen sind. 
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Ein PMP übernimmt zusätzliche Verwaltungsfunktionen. Der PMP ist für 
die Domänenhierarchie verantwortlich und stellt ähnlich dem Domain Name 
System (DNS)! einen Naming-Service für Domänen zur Verfügung. Details 
dazu finden sich in Anhang D. In jeder lokalen Domäne existiert ein PMP, der 
für die Verwaltung der Domäne verantwortlich ist. Ein zentraler Root-PMP 
steht an der Spitze der Hierarchie. Alle Komponenten registrieren sich bei 
ihrem lokalen PMP und können dort von anderen Komponenten angefragt 
werden. Ein PXP registriert außerdem die von ihm unterstützten Aktionen beim 
PMP, sobald er verfügbar ist. Der PDP kann dann bei Bedarf den passenden 
PXP beim PMP anfragen. 


Mit Hilfe des Policy Administration Point (PAP) kann ein Administrator 
neue Policies erstellen oder dem PMP bekanntmachen. Eine neue Policy kann 
insbesondere auf Veranlassung einer anderen Policy erzeugt werden. In diesem 
Fall weist ein PXP den PAP dazu an, die entsprechende Policy zu erstellen und 
über den PMP in den PDP zu laden. 


Der Provenance Collection Point (ProCP) aggregiert auf Anfrage die in den 
einzelnen ProSPs verteilt gespeicherte Provenance und stellt sie als einheitliche 
Datenstruktur zur Verfügung. Die Aggregation der Personal-Data-Provenance 
findet, in Übereinstimmung mit Anforderung 21, nur dann statt, wenn sich 
der Betroffene authentifiziert und eine Auskunftsanfrage gestellt hat. Der 
ProCP speichert selbst keine Provenance und löscht die aggregierte Provenance 
aus dem Zwischenspeicher, sobald sie an den Betroffenen ausgeliefert wurde 
(Anforderung 22). Der ProCP speichert allerdings Informationen, die zwingend 
zentral vorhanden sein müssen. Dazu zählen Authentifikationsmerkmale des 
Betroffenen, externe Stellen und das IT-System, durch das ein personenbe- 
zogenes Datum erstmalig erhoben wurde. Die Gründe werden in Kapitel 8.2 
erläutert. 


' https://tools.ietf.org/html/rfc1034. 
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Da es nur einen zentralen ProCP gibt, registriert sich dieser direkt beim 
Root-PMP. 


Der ProCP ist nicht mit dem Begriff der ,,Provenance-Collection“ aus Ab- 
schnitt 5.1 identisch. Die Komponente zur Erhebung der Provenance ist der 
PEP. Wird in den folgenden Kapiteln von „Provenance-Collection“ gesprochen, 
ist der ProCP gemeint. 


Der Provenance Dissemination Point (ProDP) erhält die, über verteilte 
Systeme hinweg aggregierte, Personal-Data-Provenance vom ProCP. Er bereitet 
die Provenance so auf, dass sie vom Betroffenen verstanden werden Kann. 
Er ist die Schnittstelle zwischen dem Datenschutzauskunftssystem und dem 
Betroffenen. Der ProDP ist die Auskunftsplattform, auch Privacy-Dashboard 
genannt. 


5.3.2 Schnittstellen und Implementierung 


Bis auf zwei Ausnahmen sind alle Komponenten der Architektur in der 
Programmiersprache Java implementiert. Sie sind dadurch plattformunabhängig 
und flexibel einsetztbar. Die beiden Ausnahmen sind der PEP und der ProDP. 


Die Realisierung eines PEP hängt von der Abstraktionsschicht ab, für die er 
eingesetzt werden soll. Soweit möglich wird ein PEP als dynamisch ladbare 
Erweiterung der Abstraktionsschicht implementiert. Für solche Erweiterungen 
sind Programmiersprache und Struktur meistens vorgegeben. 


Der ProDP, die PrivacyInsight genannte Auskunftsplattform, ist als Webanwen- 
dung umgesetzt. PrivacyInsight ist in HTML 5 und JavaScript implementiert 
und über eine REST-Schnittstelle an den ProCP angebunden. 


Die Komponenten kommunizieren über Remote Method Invocation (RMI) oder 
unter Austausch von JSON-Objekten über eine native TCP-Verbindung. Andere 
Kommunikationsprotokolle und Austauschformate sind konzeptionell nicht 
ausgeschlossen und durch eine modulare Implementierung explizit vorgesehen. 
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Die Schnittstelle des PDP ist kompakt (Listing 5.1). Die Methode notify() 
erlaubt dem PEP, auftretende Ereignisse an den PDP zu melden. Die drei 
anderen Methoden nutzt der PMP um das Laden und Zurückziehen von Policies 
anzusteuern. 


Decision notify(Event event); 

boolean deploy(Policyld policyld); 
boolean revokePolicy(Policyld policyld); 
ArrayList<Policyld> listDeployedPolicies(); 


Listing 5.1: Schnittstelle des PDP 


Die Schnittstelle des PIP (Listing 5.2) hat zunächst drei Methoden zur Re- 
gistrierung des PEP und seiner Informationsflusssemantik (siehe Kapitel 6.2 
und 8.1). Dem folgt eine Methode, um die initiale Manifestation eines Da- 
tums in einem Container festzulegen (setNewRepresentation(), siehe Kapitel 
6.1) und eine Methode, die es dem PEP erlaubt, den PIP über Ereignisse zu 
informieren (notifyEvent()). Die übrigen Methoden erlauben unterschiedliche 
Zustandsabfragen durch den PDP und PMP. 


boolean registerPEP(Componentld pep, String ifsemantic); 
boolean registerPEP(Componentld pep, String ifsemantic, String 
— remotelfsemantic); 
boolean unregisterPEP(Componentld pep); 
boolean setNewRepresentation(Datald data, Container container); 
boolean notifyEvent(Componentld pepID, Event newEvent); 
Set<Datald> getDataOfContainer(Containerld container); 
Containerld getContainerByDesignator(String designator); 
Set<Containerld> getContainerOfData(Datald data); 
boolean representationRefinesData(Containerld container, Datald data); 
boolean representationRefinesDataAfterEvent(Containerld container, 
~+ Datald data, Componentld componentID, Event event); 


Listing 5.2: Schnittstelle des PIP fiir Informationsflüsse 
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Verbindet man den PIP mit dem ProSP sind zwei zusätzliche Methoden erfor- 
derlich, die das Provenance-Tracking aktivieren beziehungsweise deaktivieren 
(Listing 5.3). 


boolean setTracking(Datald data); 
boolean abandontracking(Datald data); 


Listing 5.3: Schnittstelle des PIP fiir Provenance 


Intern ruft der PIP bei aktiver Provenance die Methoden createRepresentation() 
und terminateRepresentation() auf (siehe Kapitel 6.3). Diese Methoden wer- 
den auch gemeinsam mit der Methode addSourceMetadata() von außen zur 
Initialisierung der Provenance verwendet. Die letzten beiden Methoden in 
Listing 5.4 erlauben das Abrufen der Provenance beim ProSP. 


Containerld addSourceMetadata(String source, Datald data, String 
— dataCategory, String dataSubject); 
boolean createRepresentation(Container cont, Datald data, Containerld 
— source, String purpose); 
boolean terminateRepresentation(Containerld cont, Datald data); 
ProvenanceGraph getProvenanceOfData(Datald data); 
ProvenanceGraph getProvenanceByLocalRoot(Representationld rootID); 


Listing 5.4: Schnittstelle des ProSP 


Die Schnittstelle des PXP ist generisch und erlaubt unter Ubergabe des Ereig- 
nisses ein Ausführen der durch den PXP unterstützten Aktionen (Listing 5.5). 


boolean execute(ExecuteAction action, Event event); 


Listing 5.5: Schnittstelle des PXP 


Die Schnittstelle des PMP (Listing 5.6) erlaubt dem PAP die Ansteuerung des 
Policy-Managements, insbesondere der Instanziierung. Nicht dargestellt sind die 
Registrierung und das Abrufen der Komponenten sowie die Domänendienste. 
Der PRP erlaubt das Abspeichern (storePolicy()) und Abrufen (retrievePolicy()) 
von Policies. 
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Policyld deployPolicy(URI domain, String policy); 

Policyld deployPolicyTemplate(URI domain, String policy); 

boolean revokePolicy(URI domain, Policyld policyld); 

Policyld instantiatePolicy(URI domain, Policyld policy, Datald data); 

Policyld instantiatePolicy(URI domain, Policyld policy, Datald data, 
— Policyld pld); 


Listing 5.6: Schnittstelle des PMP 


Die ersten vier Methoden des ProCP erlauben es den ProSPs, Metadaten zur 
Provenance zu hinterlegen, die später zum Auffinden der Provenance notwendig 
sind (Listing 5.7). Die Methode getProvenanceForSubject() erlaubt es dem 
ProDP, die vollständige Provenance für einen Betroffenen abzurufen. 


boolean contains(Datald data); 

boolean setDataCollector(Datald datalD, URI domain); 

boolean addDataForSubject(Datald data, Subjectld dataSubject); 
ExternalContainer getExternalContainer(String description); 
ProvenanceGraph getProvenanceForSubject(Subjectld dataSubject); 


Listing 5.7: Schnittstelle des ProCP 


PAP und ProDP haben bis auf die grafische Benutzerschnittstelle keine Schnitt- 
stellen. 


5.3.3 Sicherheitsannahmen 
Den Überlegungen der folgenden Kapitel liegen die folgenden Annahmen zur 
Sicherheit des Datenschutzauskunftssystems zu Grunde: 


e Das Datenschutzauskunftssystem ist korrekt implementiert und frei von 
Bugs. 


e Das Datenschutzauskunftssystem wird vor seinem Einsatz in allen IT- 
Systemen korrekt aufgesetzt. 
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e Die verbundenen Komponenten des Datenschutzauskunftssystems lau- 
fen immer dann in einer lokalen Domäne, wenn eine Verarbeitung 
personenbezogener Daten stattfindet (Anforderung 54). 


e Eine Modifikation des Datenschutzauskunftssystems durch die datenver- 
arbeitenden Organisationseinheiten ist nicht möglich (Anforderung 39). 


e Ein Umgehen des Provenance-Trackings ist nicht möglich oder wird 
organisatorisch unterbunden (Anforderung 54). 


e Ein Zugriff auf die Provenance ist nur nach Authentifikation durch den 
Betroffenen über die implementierten Schnittstellen möglich (Anforde- 
rung 30 ff.). 


e Jeder Zugriff auf die Provenance einer lokalen Domäne wird revisi- 
onssicher protokolliert. Abfragen des ProCP, die nicht auf eine Betrof- 
fenenanfrage gestützt sind, können entdeckt und sanktioniert werden 
(Anforderung 40). 


e Die Kommunikation zwischen den Komponenten des Datenschutzaus- 
kunftssystems wird durch starke Kryptographie geschützt. 


Nichtsdestotrotz ist das Datenschutzauskunftssystem grundsätzlich kein Si- 
cherheitssystem. Der verantwortlichen Stelle muss zumindest soweit vertraut 
werden, dass sie keine Hintertüren in ihre eigenen IT-Systeme einbaut. Daten- 
schutz funktioniert nur durch ein Zusammenspiel organisatorischer, rechtlicher 
und technischer Maßnahmen. Technische Defizite, die in der Softwareent- 
wicklung immer vorkommen, können durch organisatorische Maßnahmen 
ausgeglichen werden. 


5.4 Zwischenfazit 


Neben einem Überblick über Provenance-Tracking und Usage-Control wurde 
in diesem Kapitel eine verteilte, generische Architektur für ein Datenschutz- 
auskunftssystem vorgestellt, die beides verbindet. Provenance-Tracking und 
Usage-Control erlauben gemeinsam die Durchsetzung von Transparenz und 
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Intervenierbarkeit. Die Betroffenenrechte werden ganzheitlich angegangen. Die 
vorgeschlagene Architektur erfüllt die in Konstruktionsziel A2 aufgestellten 
Bedingungen. 
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Um den Umgang mit personenbezogenen Daten im geforderten Umfang be- 
auskunften zu können, muss der Fluss personenbezogener Daten vollständig 
nachvollzogen werden können. Kopien der erhobenen personenbezogenen 
Daten und von ihnen abgeleitete Daten behalten den Personenbezug und sind 
auskunftspflichtig.' Der Kern des Datenschutzauskunftssystems ist deshalb 
die Infrastruktur zur Erfassung des aktuellen Informationsflusszustands und 
zur Speicherung der Provenance. In diesem Kapitel wird zunächst das aus 
dem Usage-Control-Umfeld stammende Informationsflussmodel eingeführt 
und erweitert (Abschnitt 6.1). Gemäß dieses Modells wird der jeweils aktuelle 
Informationsflusszustand (Abschnitt 6.1) im PIP gespeichert. 


Die Erfassung des Informationsflusszustands erfolgt anhand der durch die 
PEPs der einzelnen Abstraktionsschichten übermittelten Ereignisse. Die Art 
dieser Ereignisse unterscheidet sich je nach Abstraktionsschicht und ist dem 
PIP a priori unbekannt. Um unterschiedliche Systeme und Applikationen in die 
Datenschutzauskunft einbinden zu können, wird in Abschnitt 6.2 ein Schema 
zur semantischen Beschreibung von Informationsflüssen (Informationsflussse- 
mantik) in Abhängigkeit von Ereignissen eingeführt. 


Die Provenance an sich, also die datenbezogene Historie des Informationsflus- 
ses, wird getrennt vom Informationsflusszustand in einer eigenen Datenstruktur 
abgelegt (Abschnitt 6.3.1). Diese konzeptionelle Entscheidung hat den Vor- 
teil, dass die Granularität der Provenance, den Anforderungen zum Umfang 


! Sofern sie nicht anonymisiert werden. 
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einer Datenschutzauskunft entsprechend (Anforderung 5 ff.), gröber als die 
Granularität des Informationsfluss-Trackings sein kann. Die darüber hinausge- 
henden Vorteile dieses Konzeptes beim Entwurf eines speicherskalierbaren 
Datenschutzauskunftssystems werden im Kapitel 7 besprochen. 


Dennoch sind das Informationsflussmodell und das Personal-Data-Provenance- 
Modell eng miteinander verzahnt. Der Zustand des letzteren leitet sich aus dem 
des ersteren ab (Abschnitt 6.3.2). 


Die wichtigsten Aspekte der Implementierung der Provenance-Datenhaltung 
werden am Ende des Kapitels erläutert (Abschnitt 6.4). 


6.1 Usage-Control-Informationsflussmodell 


Pretschner und Harvan haben das Informationsflussmodell für Usage-Control 
formal als Tupel (7, @, F, X, &, 7) eingeführt. ! 


9 ist die Menge aller personenbezogenen Daten. @ ist die Menge aller 
Container. Ein Container ist ein Ort, an dem sich ein Datum in einem IT- 
System manifestiert. Beispielsweise kann sich ein Profilfoto von Alice in einer 
Datei im Dateisystem, in einer Datenbank und gleichzeitig in einem Fenster 
des Fenstermanagers manifestieren. Neben Speicherorten werden je nach 
Abstraktionsniveau auch Prozesse, Kommunikationskanäle und ganze Stellen 
als Container aufgefasst. Die Unterscheidung zwischen Daten und Containern 
ist der zentrale Aspekt des Modells. .7 ist die Menge aller Bezeichner, die 
Container eindeutig identifizieren. 


“= (€ P(2) x (€ > P(@)) x (F — @) ist die Menge aller Zu- 
stände, bestehend aus den folgenden drei Abbildungen: Die Speicherfunktion 
s : € — P(2) bildet ab, welche Daten sich in welchen Containern befinden. 
Die Aliasfunktion | : € — P(€) beschreibt eine implizite Abhängigkeit 
des Zustands von Containern bezüglich eines Datums. Ändert sich die Spei- 
cherfunktion des Containers cı € C, ändert sich entsprechend auch die 


1 Harvan/Pretschner 2009; Pretschner/Lovat/Biichler 2011. 
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Speicherfunktion eines jeden Containers cz € I(c,). Die Benennungsfunktion 
f: F — € bildet Bezeichner auf Container ab. oo = (0,0,0) € È ist der 
initiale Systemzustand. 


Ereignisse (Events) & sind beobachtete Vorgänge, die Änderungen im System- 
zustand widerspiegeln. Ereignisse resultieren in Änderungen der Speicher-, 
Alias- und Benennungsfunktion. Die Übergänge werden durch die (determi- 
nistische) Relation Z C © x & x X beschrieben. 


Im Modell werden drei unterschiedliche Containermengen unterschieden: An 
erster Stelle sind reale Container 6peal, die Orte beschreiben, an denen sich 
Daten befinden können, Teil des Modells. Darüber hinaus werden abstrakte 
Container ©,»str modelliert. Sie fassen die unterschiedlichen realen Container 
in einem gemeinsamen Zustand zusammen und abstrahieren von der durch 
das Informationsflussmodell gegebenen Granularität auf die für Provenance 
erforderliche Granularität. Ein abstrakter Container vereint in sich alle Spei- 
cherfunktionen der zugrundeliegenden realen Container. Reale Container und 
abstrakte Container werden über eine unidirektionale Aliasrelation miteinander 
verbunden.! Als dritte Menge werden virtuelle Intermediate-Container %, 
modelliert. Sie bilden eine Brücke zwischen unterschiedlichen Abstraktions- 
schichten innerhalb eines IT-Systems sowie zwischen IT-Systemen.? Ergänzend 
existiert der spezielle Container nil, auf den Namen abgebildet werden, die 
noch keinem konkreten Container zugeordnet sind. Insgesamt ergibt sich 
C = Creal U Cabstr UG, U {nil}. Seat, Cabstr und ©, sind paarweise disjunkt. 


Beispiel. Insgesamt verarbeitet AdBokis 30 personenbezogene Daten de 2 
ihrer beiden Kunden in 17 Datenkategorien 0 € ©. In Tabelle 6.1 sind 
exemplarisch die personenbezogenen Daten von Alice Fox aufgelistet. 


Über das Informationsflussmodell hinaus ist es für den Anwendungsfall der Da- 
tenschutzauskunftssysteme erforderlich, ergänzend die Menge der Betroffenen 
B einzuführen. Die Personenbezugsfunktion n : Z — P(2) weist jedem 
Betroffenen diejenigen Daten zu, die einen Personenbezug zu ihm besitzen. 


' Vel. Kapitel 7.2. 
2 Vgl. Kapitel 8. 
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Tabelle 6.1: Personenbezogene Daten von Alice 


d, 0, Datenkategorie Inhalt 

1 1 Vorname Alice 

2 2 Name Fox 

3 3 e-Mail alice. fox@honigmail.de 
4 4 Telefonnummer +49 721 6091-0 

5 5 Geburtsdatum 15.05.1985 

6 6 Rechnungsadresse Hansastraße 27c 

7 7 Lieferadresse Fraunhoferstr. 1 

8 7 Lieferadresse PostNummer 7654321 
9 8  Wohnsitzstaat Germany 

10 9 Zustellungsart Lieferung nach Hause 
11 9  Zustellungsart Packstation 

12 10 IBAN DE19 1234 1234 1234 1234 12 
13 11 Kreditkartentyp Master Card 

14 12 Kreditkartennummer 4343 9534 4301 1007 
15 13 Ablaufdatum der Kreditkarte Dez 21 

16 14 Profilbild [nicht darstellbar] 

17 15 IP-Adresse 217.146.191.19 

18 15 IP-Adresse 31.130.202.80 

19 16 Empfehlung Inges Braustubenführer 
20 17 Rechnung [nicht darstellbar] 


Beispiel. AdBokis hat im Minimalbeispiel zwei Kunden (Betroffene b € B): 
Alice Fox (bı) und Peter Trollig (bə). 


Die Architektur des Datenschutzauskunftssystems sieht vor, dass der Zustand 
o im PIP vorgehalten wird. Des Weiteren sollen PEPs dynamisch zur Laufzeit 
hinzugefügt werden können. In der Konsequenz ist der PEP die Komponente, die 
den Teil der Übergangsrelation .7 spezifiziert, der die von ihm weitergereichten 
Ereignisse betrifft. Durch diese Trennung ist dem PIP die Übergangsrelation 
zunächst unbekannt. 


Deshalb registriert sich ein PEP beim PIP, sobald er zu einem Datenschutz- 
auskunftssystem hinzugefügt wird (Methode registerPEP()). Im Zuge dessen 
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wird dem PIP vom PEP die semantische Spezifikation des Teils der Uber- 
gangsrelation bekannt gemacht, der die vom jeweiligen PEP abgefangenen und 
weitergereichten Ereignisse betrifft. Der nachfolgende Abschnitt erläutert das 
dahinterstehende Modell und die Realisierung der Spezifikation. 


6.2 Semantische Beschreibung der 
Übergangsrelation 


Der jeweilige Abschnitt der Übergangsrelation Z ist für jeden PEP in einer 
Informationsflusssemantik spezifiziert. Für jedes vom PEP abgefangene Ereignis 
gibt die Informationsflusssemantik die Zustandsübergänge der Funktionen 
s, | und f an. Eine Informationsflusssemantik entspricht dem Schema in 
Anhang E.1. Um die semantische Spezifikation für die Praxis handhabbar 
zu machen, enthält sie nicht direkt die Beschreibung der Übergangsrelation, 
sondern benutzt generische Primitive. 


6.2.1 Generische Primitive zur Beschreibung der 
Informationsflusssemantik 


Die generischen Primitive,'! Hilfsfunktionen zur Beschreibung von Zustands- 
übergängen, definieren alle Änderungen des Informationsflussmodells, die in 
einer Semantik spezifiziert werden können. Sie werden bei der Verarbeitung 
eines Ereignisses durch den PIP nacheinander gemäß der Informationsflussse- 
mantik aufgerufen und modifizieren die Funktionen s, l und f. Sie werden im 
Folgenden beschrieben; ein Anwendungsbeispiel wird im Anschluss vorgestellt 
(Abschnitt 6.2.2). 


Um die Veränderungen der Funktionen s, l und f durch Ereignisse zu be- 
schreiben, wird auf die Notation aus den Arbeiten von Harvan und Pretschner 


! Die Primitive wurden bereits in Birnstill/Bier et al. 2016 eingeführt. 
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zurückgegriffen.! Sei m : A— B eine beliebige Abbildung und a € A ein 
Element der Urbildmenge. Dann ist m[a + exprlaea = m’ mitm’: A > B 
definiert als 


expr jira’ =a 
m’(a’) = pe 
m(a’) sonst. 


Generische Primitive zum Update der Speicherfunktion 


Die Speicherfunktion hält die Abbildungen zwischen Daten und Containern 
vor. Sie ist die zentrale Funktion zur Modellierung von Informationsflüssen. 


Das erste Primitiv für die Speicherfunktion ist das flow-Primitiv. Es bezeichnet 
den Fluss einer Menge von Daten {d; } 1<i<nen in einen Container c. Zusätzlich 
findet der Fluss in die referenzierten abstrakten Container statt. Das flow- 
Primitiv wird beispielsweise verwendet, um zu modellieren, dass eine neue 
Datei oder ein neuer Prozess erzeugt wird oder dass eine Datei kopiert wird. 


Primitiv 1: flow(o, c, {di}i<i<nen) 
(s,l,f)<co 
s + s|c + s(c) U {di}i<i<nen] 
forall u € l(c) N Cabstr do 
| s + s[u + s(u) U {d;}ı<i<nen] 
end 
return (s,/, f) 


Findet der Fluss nicht nur in einen Container statt, sondern sind mehrere 
Container logisch miteinander verbunden, findet das Primitiv 2 Anwendung. 


! Harvan/Pretschner 2009. 
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Liest beispielsweise ein Prozess Daten ein und wird dieser Prozess im Fenster 
eines Fenstermanagers visualisiert, dann findet der Fluss nicht nur in den 
Speicherbereich des Prozesses, sondern auch in das Fenster statt. /* ist die 
reflexiv-transitive Hülle von l. Uber sie lassen sich alle Container in Ketten 
von Aliasrelationen adressieren. 


Primitiv 2: flow_to_rtc(o, c, {di }i<i<nen) 
(s, l, f) res o 
forall u € !*(c) do 
| s+ s|u = s(u) U {d;hı<i<nen] 
end 
return (s,/, f) 


Das clear-Primitiv 3 wird eingesetzt, wenn ein Container gelöscht oder über- 
schrieben wird. Beispiele sind das Schließen eines Fensters oder das Löschen 


einer Datei. 


Primitiv 3: clear(o, c) 
(s,l, f) 0 
s + sic + &] 
forall u € l(c) N Cabstr do 
| s s[u + Usec ucio) s(v)] 
end 
return (s,/, f) 
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Um den Léschvorgang auf die abstrakten Container zu tibertragen, wird 
zusätzlich der Speicherzustand aller referenzierten abstrakten Container auf 
Grundlage der auf sie verweisenden realen Container aktualisiert. 


Generische Primitive zum Update der Aliasfunktion 


Die Aliasfunktion definiert die Beziehungen zwischen unterschiedlichen Con- 
tainern, die zu impliziten Informationsflüssen führen können. Wann immer 
ein Datum in den ersten Container Com fließt, wird es auch in den per Alias 
verbundenen Container c;, fließen. 


Das Primitiv 4 fügt einen unidirektionalen Alias von Cyrom nach cto hin- 
zu. Beispielsweise kann so die Beziehung einer gespiegelten Datei zu einer 
Originaldatei, auf die nur Lesezugriff besteht, beschrieben werden. 


Primitiv 4: create_alias(o, Cfrom, Cto) 
(s,1,f) = 0 


I l[Cfrom + L(Cfrom) U {Cto}] 
return (s,/, f) 


Zum Aufbau bidirektionaler Aliase wird das Primitiv 5 verwendet. Es findet 
beispielsweise Anwendung, wenn zu einem Prozess ein Fenster erzeugt wird. 


Primitiv 5: create_bidir_alias(a, Cfrom, Cto) 
(s,l, f) = 0 
l- I[¢from — U(Cfrom) U {cto}] 


l [cto — U(cto) U {Cfrom }] 
return (s,/, f) 
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Das Primitiv 6 ist das Inverse von Primitiv 4. Es entfernt genau einen Alias. 


Primitiv 6: rm_alias_locally(o, Cfrom, Cto) 
(s,l, f) 0 
l- l[efrom s~ Ic from) \ {cto}] 
return (s,/, f) 


In manchen Fallen ist es notwendig, alle unidirektionalen Aliase auf einen 
Container zu entfernen, beispielsweise wenn dieser gelöscht wird. Dies erfolgt 


mit Primitiv 7. 


Primitiv 7: rm_alias_globally(o, Cto) 


(s,l, f) = 0 
forall c € C do 
| le lee lc) \ {coy 


end 
return (s,l, f) 


Das Primitiv 8 ist das Gegenstück zu Primitiv 7. Es entfernt alle Aliase, die 


von einem bestimmten Container ausgehen. 


Primitiv 8: clear_aliases(o, c) 


(5,1, f) = 0 
le lje + ø] 
return (s,/, f) 
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Bidirektionale Aliase werden mit Primitiv 9 entfernt. Es ist das Inverse des 
Primitivs 5. 


Primitiv 9: rm_bidir_alias_locally(o, C from, Cto) 
(3, f) = 0 
le- l[efrom = U(Cfrom) \ {cto}] 


le UCto — U(Cto) \ {cfrom}] 
return (s,/, f) 


Generische Primitive zum Update der Benennungsfunktion 


Die Benennungsfunktion weist Containern Bezeichner zu. Beispielsweise 
werden Dateien über Dateinamen und über Datei-Handles adressiert. 


Einem Container wird ein neuer Bezeichner d € J mit Hilfe des 
add_naming-Primitivs 10 zugewiesen. 


Primitiv 10: add_naming(o, ¢, c) 
(3,1, f) 0 
fe- flee d 


return (s,l, f) 


Das inverse Primitiv des add_naming-Primitivs ist das letzte generische 
Primitiv rm_naming. 
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Primitiv 11: rm_naming(o, ¢) 
(3,1, f) = 0 


f < fle < nil] 
return (s,/, f) 


6.2.2 Anwendung der Informationsflusssemantik im PIP 


Der PIP erzeugt die Ubergangsrelation J (ø, e) anhand der Informationsfluss- 
semantiken der bei ihm registrierten PEPs aus den generischen Primitiven. 


Die Informationsflusssemantik enthält drei Arten von Informationen: (1) Wel- 
che generischen Primitive die Übergangsrelation für ein bestimmtes Ereignis 
beschreiben, (2) in welcher Reihenfolge sie aufzurufen sind und (3) welche 
Parameter eines Ereignisses auf die in der Signatur der generischen Primitive 
verwendeten Variablen abgebildet werden müssen. 


Für jeden Parameter eines Ereignisses wird in der Informationsflusssemantik 
sein Typ angegeben. Mit den Parametertypen spezifiziert die Informationsfluss- 
semantik, welcher Parameter eines Ereignisses als Datum (d € 2), Container 
(c € G) oder Bezeichner (d € F) aufzufassen ist. ! 


Ist durch den PIP ein Ereignis auszuwerten, werden die Funktionen f und 
s auf jeden Parameterwert des Ereignisses so angewandt, dass der Typ der 
resultierenden Werte mit den Variablen in der Signatur der aufzurufenden 
Primitive übereinstimmt. Die generischen Primitive werden anschließend 
nacheinander aufgerufen. 


Die konkrete Auswertung der Informationsflusssemantik sowie die einzelnen 
Aspekte der Ereignisverarbeitung werden nachfolgend anhand eines Beispiels 
erläutert. 


! Auch Datenmengen und Containermengen sind möglich. Deren Elemente werden einzeln 
konvertiert. 
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Beispiel. Ein Mitarbeiter der AdBokis kopiert eine Datei mit Kundendaten 
aus einem temporären Verzeichnis auf den Desktop. 


<?xml version="1.0" encoding="UTF—8"?> 
<ifsemantic> 
<params> 
<param name="newFileName" type="DESIGNATOR" /> 
<param name="oldFileName" type="DESIGNATOR" /> 
</params> 
<actions> 
<action name="CopyFile"> 
<operation name="SF_CLEAR"> 
<left> 
<operand>newFileName</operand> 
</left> 
<right></right> 
</operation> 
<operation name="SF_FLOW_TO_RTC"> 
<left> 
<operand>newFileName</operand> 
</left> 
<right> 
<operand>oldFileName</operand> 
</right> 
</operation> 
</action> 
</actions> 
</ifsemantic> 


Listing 6.1: Informationsflusssematik fiir das Copy-Ereignis des Windows-PEP 


Nach dem Start des Betriebssystems registriert sich der Windows-PEP beim PIP 
und übergibt seine Informationsflusssemantik. Listing 6.1 zeigt den Ausschnitt 
der Informationsflusssemantik für die Kopieroperation (CopyFile). Die Seman- 
tik gibt für die beiden relevanten Parameter der Ereignisse, newFileName und 
oldFileName, den jeweiligen Typ an. Beide Parameter sind Bezeichner (F). 
Die anschließenden Aktionsbeschreibungen geben für jede Ereigniskategorie 
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die zu verwendenden Primitive und ihre Parameter an. Ein CopyFile-Ereignis 
erfordert die Anwendung der Primitive 2 (flow_to_rtc) und 3 (clear). 


Sobald der Windows-PEP dem PIP ein CopyFile-Ereignis weiterleitet (Lis- 
ting 6.2), wertet der PIP das Ereignis gemäß der gegebenen Semantik aus. 
Zunächst wird geprüft, ob alle in der Semantik angegebenen Parameter vorhan- 
den sind. Ist dies der Fall, werden die Typen der Parameter mit den Signaturen 
der Primitive verglichen. Das Primitiv flow_to_rtc erwartet gemäß seiner 
Signatur einen Container und eine Menge von Daten. Die Parameter des Er- 
eignisses sind jedoch jeweils vom Typ „Bezeichner“. Deshalb werden sie vor 
Ausführung der Primitive in die Zieltypen umgewandelt. Für den oldFileName 
sieht das wie folgt aus: s(f(C:\tmp\customers.csv)) = {dı,...,d„}. Die 
Ausführung der Primitive sorgt dafür, dass der Zielcontainer zunächst keine 
Speicherrelation mehr besitzt und ihm dann alle Daten des Quellcontainers 
zugewiesen werden. 


<event action="CopyFile" timestamp="2016—07—10T21:00:00"> 
<parameter name="ProcessName" value="cp.exe"> 
<parameter name="PID" value="2924"> 
<parameter name="ProcessOwner" value="bi"> 
<parameter name="TID" value="4040"> 
<parameter name="oldFileName" value="C:\tmp\customers.csv"> 
<parameter name="newFileName" 
= value="C:\Users\bi\Desktop\customers.csv"> 
</event> 


Listing 6.2: Copy-Ereignis des Windows-PEP 


Die Parameter des Ereignisses, die fiir die Informationsflussverarbeitung nicht 
relevant sind (z. B. ProcessOwner), werden ignoriert. 
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6.3 Provenance-Datenmodell 


Das Informationsflussmodell repräsentiert den Zustand eines Systems zu einem 
bestimmten Zeitpunkt. Für die Datenschutzauskunft ist die durchgängige Histo- 
rie der Informationsflüsse erforderlich, die Provenance der personenbezogenen 
Daten. Im Folgenden wird beschrieben, wie die Provenance aus dem Zustand 
des Informationsflussmodells und den Ereignissen abgeleitet werden kann, die 
Zustandsänderungen auslösen. 


6.3.1 Personal-Data-Provenance-Datenmodell 


Das Provenance-Datenmodell dokumentiert den Umgang mit personenbe- 
zogenen Daten über die Zeit. Es ist ein Graph, genauer ein Wald, in dem 
genau ein Baum (Out-Tree) für jedes Datum steht. Die Wurzel eines Baumes 
entspricht der Erhebung personenbezogener Daten bei einer Stelle außerhalb 
der verantwortlichen Stelle. Jeder weitere Knoten repräsentiert einen Verarbei- 
tungsvorgang, eine Datenspeicherung, eine Datenweitergabe oder eine weitere 
externe Stelle. Die Kanten stehen für die Informationsflussbeziehungen. 


Ein Provenance-Graph ist definiert als ein Wald Z = (#, .Z)) bestehend aus 
den Knoten (Repräsentationen) Z C 2 x € x N und den gerichteten Kanten 
LC& x % zwischen diesen Knoten. Ein Knoten steht für die Repräsentation 
eines Datums in einem Container zu einem bestimmten Zeitpunkt. Der Zeit- 
punkt einer Repräsentation ist ihr Entstehungszeitpunkt, also jener Moment, in 
dem das Datum in einen Container geflossen ist, in dem es sich zuvor nicht 
befunden hat. Eine Kante beschreibt den Informationsfluss eines Datums von 
einem Container zu einem anderen. Sie verbindet die Repräsentation, die für die 
Beziehung Datum-Quellcontainer zum Zeitpunkt des Informationsflusses steht, 
und die Repräsentation, die durch den Informationsfluss in den Zielcontainer 
neu entsteht. 


Dass für jedes Datum genau ein Baum im Provenance-Graphen existiert, ist wie 
folgt begründet: Ist ein Datum bereits erhoben, ist für dessen Verwendung keine 
weitere Erhebung mehr erforderlich. Gibt es mehrere Erhebungen desselben 
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Datums, kann dies nur darin begriindet liegen, dass das Datum durch die 
erhebende Stelle nicht wiedererkannt wird. Die beiden Bäume werden dann 
wie die von zwei unterschiedlichen Daten behandelt. Es gibt keine geschlos- 
senen Pfade, da ein Datum nirgendwohin flieBen kann, wo es bereits ist. Im 
Informationsflussmodell kann nur dann eine neue Kante zwischen Datum und 
Container entstehen, wenn zuvor d ¢ s(c) war. Somit ist die Baumstruktur der 
Provenance sichergestellt. 


Auf einer Repräsentation ist ergänzend die Funktion term : Z > N U nil 
definiert. Sie weist jeder Repräsentation einen Terminierungszeitpunkt zu. 
Der Terminierungszeitpunkt ist der Zeitpunkt, zu dem sich das repräsentierte 
Datum seit dem Entstehungszeitpunkt erstmalig nicht mehr im referenzierten 
Container befindet. Solange die Repräsentation besteht, verweist term auf nil. 


6.3.2 Verbindung von Informationsfluss- und 
Provenance-Datenmodell 


Die Aktualisierung des Provenance-Graphen zur Laufzeit hängt direkt mit den 
Veränderungen des Systemzustands % im Informationsflussmodell zusammen. 
Änderungen der Speicherfunktion, sprich Informationsflüsse und Informations- 
löschungen, resultieren in Änderungen des Provenance-Graphen. Im Folgenden 
werden die beiden möglichen Modifikationen der Speicherfunktion und ihre 
Auswirkungen auf den Provenance-Graphen formal dargestellt. 


Die erste mögliche Änderung der Speicherfunktion wird im Informationsfluss- 
modell durch das Primitiv flow (s[c + s(c) U d]), dem Fluss eines (neuen) 
Datums in einen Container, ausgelöst.! Sei % = (Z;, Z) der Provenance- 
Graph zum Zeitpunkt t € N, dann entstehen neue Repräsentationen im 
Graphen %,,, in Abhängigkeit von den Zuständen o; = (s+, l+, fr) und 
Orsi = (St+1, 4441, ft+ı). Für jedes Datum d € 9, das einem Container 


! Die Primitive flow und flow_to_rtc sind in diesem Grundverhalten äquivalent. 
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c € @ neu zufließt, wird im Provenance-Graphen eine neue Repräsentation 
erzeugt: ! 


VdEGVCESE: 
d & sı(c) Nde st+1(c) N lle) N Cabstr = ) —r (d, c,t+ 1) € Riv 


Da immer nur dann eine neue Repräsentation für eine Datum-Container- 
Kombination in ¢ + 1 zum Provenance-Graph hinzugefiigt wird, wenn im 
zugrundeliegenden Informationsflussmodell zum vorhergehenden Zeitpunkt t 
noch keine Relation zwischen diesen beiden Elementen bestand (d ¢ sı(c)), 
kann immer nur maximal eine Repräsentation zu einer Datum-Container- 
Kombination existieren, die noch keinen Terminierungszeitpunkt besitzt. 


Ebenso wie das Erzeugen der Repräsentationen beruht das Hinzufügen da- 
zwischenliegender Kanten auf den Änderungen des Informationsflussmodells 
durch die generischen Primitive. Eine Kante geht von einer Repräsentation aus, 
die noch keinen Terminierungszeitpunkt aufweist, hin zur neu entstandenen 
Repräsentation. Eine Kante beschreibt den Informationsfluss des Datums d 
von Container cı zum Container cz zum Zeitpunkt t + 1. 


Nur wenn ein Informationsflussereignis in seinen Parametern die Quelle des 
Informationsflusses, einen Container, mitangibt (s[cı + s(c2) U s(cı)])” 
bleibt der Provenance-Baum für jedes Datum verbunden und es werden Kanten 
zu £ hinzugefügt. Diese Kanten verbinden im aktualisierten Provenance- 
Graphen 4,1 für alle d € s;(cı) die Repräsentationen (d, c1, z) mit den neuen 
Repräsentationen (d, c2,t + 1). 


Beispiel. Ein Fluss personenbezogener Daten wirkt sich wie folgt aus: 
Für eine Datei mit Kundendaten d,,...,d, im temporären Verzeich- 
nis cı existieren vor Beginn der Kopieroperation die Repräsentationen 
(di, c1, t1), ---, (dn, C1, t1). tı ist der Zeitpunkt, zu dem die Kundendaten 


! Flüsse in Container, die auf abstrakte Container (G,pstr) verweisen, werden nicht in die 
Provenance mit aufgenommen; siehe dazu Kapitel 7.2. 
? Die Anwendung von s wird durch die Informationsflusssemantik spezifiziert (vgl. Abschnitt 6.2.2). 
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im tempordren Verzeichnis abgelegt wurden. Durch die Kopieroperation 
zum Zeitpunkt tz entstehen, nach Interpretation des Primitivs flow_to_rtc, 
die neuen Repräsentationen (dı,ca,ta2),..-,(dn,c2,t2) in der Datei auf 
dem Desktop ca. Neue und alte Repräsentationen sind durch die Kanten 
((dı,cı,tı), (di, c2, t2)),---, (dn, C1, t1), (dn, C2, t2)) miteinander verbun- 
den. Dadurch wird in der Provenance ersichtlich, dass die Daten in tz vom 
temporären Verzeichnis auf den Desktop gelangt sind. Im Informationsfluss- 
modell ist diese Information nicht vorhanden. 


Die zweite mögliche Modifikation der Speicherfunktion wird im Informations- 
flussmodell durch das Primitiv clear, der Entfernung aller Daten aus einem 
Container, ausgelöst. Eine Repräsentation erhält einen Terminierungszeitpunkt, 
wenn die Relation zwischen ihrem Datum und ihrem Container aus dem 
Zustand des Informationsflussmodells entfernt wird (s[e + s(c)\{d}]): 


VdEYVEEÄIZEN: 
d E si(c) AdE stile) > term((d,c,z)) =t+1 


Als Nebenbedingung gilt, dass eine Repräsentation ihren Terminierungszeit- 
punkt nicht vor ihrem Entstehungszeitpunkt haben kann. 


6.4 Implementierung der 
Provenance-Datenhaltung 


Die Personal-Data-Provenance wird im ProSP gespeichert und gemäß dem 
Schema aus dem vorherigen Abschnitt aus dem Informationsflussmodell des PIP 
generiert. Die Datenstruktur ist in Abbildung 6.1 als UML-Klassendiagramm 
dargestellt. Die Kanten zwischen den Repräsentationen werden als Vorgänger- 
attribut predecessor und Menge von Nachfolgern successor abgespeichert. 


Für jede Repräsentation wird festgelegt, welche Rolle sie im daten- 
schutzrechtlichen Sinne inne hat. Sie wird dadurch so klassifiziert, dass 
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die datenschutzrechtlichen Anforderungen aus Kapitel 4.4 auf sie ab- 
gebildet werden können. Die Rolle einer Repräsentation wird in ih- 
rem Repräsentationstyp festgelegt. Mögliche Repräsentationstypen sind 
Herkunft (SourceRepresentation), Empfänger (SinkRepresentation), Erhe- 
bung (CollectionRepresentation), Übermittlung (TransferRepresentation), 
interne Weitergabe (InternalCommunicationRepresentation), Speicherung 
(StorageRepresentation) oder Verarbeitung (Process—Representation). Re- 
präsentationstypen sind containerabhängig. Deshalb haben zwei Repräsen- 
tationen in ein und demselben Container denselben Repräsentationstyp. Die 
Repräsentationstypen sind, wo nötig, durch Vererbung und zusätzlich durch 
ein eigenes Attribut realisiert. 


Zusätzlich zu den zeitlichen Angaben einer Repräsentation sowie ihrem Typ 
werden noch weitere Metadaten gesammelt. Der Bedarf für jedes Attribut der 
Repräsentation leitet sich aus den technischen Anforderungen an den Umfang 
der Protokollierung in einem Datenschutzauskunftssystem ab. 


Die Anforderungen 7, 9, 10, 11, 12 und 15 geben den Zweck jeder Verwendung 
personenbezogener Daten sowie den Zeitpunkt von Erhebung, Weitergabe 
und Übermittlung als Teil der Provenance vor. Beides ist deshalb in der 
Datenstruktur als Attribut einer Repräsentation vorhanden. 


Um die gespeicherten personenbezogenen Daten selbst und die Metadaten der 
Speicherung beauskunften zu können, ist in Anforderung 15 die Protokollierung 
des Speicherortes festgelegt. Dieser findet sich als weiteres Attribut in der 
Speicherrepräsentation. 


Die Kategorisierung der Daten ist gemäß der Anforderungen 7, 9 und 10 für die 
Außenbeziehungen der verantwortlichen Stelle vorgesehen. Deshalb findet sich 
die Datenkategorie (Bsp.: Anschriften) in der Klasse „Data“ wieder, auf die in 
externen Repräsentationen, den Stellvertretern für Herkunft und Empfänger, 
verwiesen wird. Zum Datum selbst und zum Betroffenen wird ansonsten nur 
eine ID als Pseudonym gespeichert. 
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Die Provenence wird im ProSP im Arbeitsspeicher sowie wahlweise in der gra- 
phenbasierten Datenbank Neo4J gespeichert.! Neo4J erlaubt hochperformante 
Abfragen auf Graphen,” wie dem Personal-Data-Provenance-Datenmodell, und 
ist somit fiir eine persistente Datenhaltung der Provenance ideal geeignet. Die 
persistente Speicherung in der Datenbank kann fiir jeden ProSP einzeln zu- 
oder abgeschaltet werden. 


6.5 Zwischenfazit 


Das vorangegangene Kapitel hat gezeigt, wie sich die fiir die Datenschutz- 
auskunft erforderliche Provenance aus dem UC-Informationsflussmodell ab- 
leiten lässt und wie alle für die Auskunft relevanten Informationen in einer 
Provenance-Datenstruktur abgelegt werden können. Die ergänzend eingeführte 
semantische Beschreibungssprache für Ereignisse (Informationsflusssemantik) 
erlaubt das Hinzufügen von PEPs zum Datenschutzauskunftssystem zur Lauf- 
zeit. Dadurch können Geschäftsprozesse zur Verarbeitung personenbezogener 
Daten jederzeit flexibel umgestaltet werden. 


Die wissenschaftlichen Beiträge dieses Kapitels lassen sich wie folgt zu- 
sammenfassen: (1) Eine Erweiterung des Informationsflussmodells um den 
Betroffenen und unterschiedliche Containertypen sowie die Ergänzung der 
Informationsflusssemantik, (2) ein Datenmodell für Personal-Data-Provenance 
und (3) die Verbindung zwischen Informationsflussmodell und Personal-Data— 
Provenance-Modell. 


Auf Grundlage dieser Ergebnisse sind, wie in Konstruktionsziel A3 postuliert, 
eine generische, datenzentrierte und semantisch konfigurierbare Erfassung von 
Ereignissen und eine Speicherung von Personal-Data-Provenance in einem 
Datenmodell gemäß der datenschutzrechtlichen Anforderungen möglich. 


l https://neo4j.com. 
2 Vicknair et al. 2010. 
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Die Trennung zwischen Informationsflussmodell und Personal-Data- 
Provenance erlaubt, die Granularität des Informationsflusstrackings und der 
Provenance unterschiedlich zu gestalten. Dieses Potential wird im folgenden 
Kapitel dazu genutzt, eine speichereffiziente und datenminimale Provenance- 
Datenhaltung umzusetzen. 
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Eine Datenschutzauskunft muss vollständig sein, also insbesondere alle Wei- 
tergaben personenbezogener Daten umfassen. Um dies zu erreichen, ist ein 
detailliertes Informationsfluss-Tracking auf Betriebssystems- und Anwen- 
dungsebene notwendig. Nur so lässt sich eine unvollständige oder fehlerhafte 
Annahme über den Fluss personenbezogener Daten weitestgehend vermeiden. 


Auf der anderen Seite würden extrem detaillierte Protokolle jeden Umgangs 
mit personenbezogenen Daten den Grundsatz der Datenminimierung verletzen 
(Kriterium 40) und die mit der Datenverarbeitung betrauten Mitarbeiter einem 
besonderen Überwachungsrisiko aussetzen. Nahezu jeder Mausklick würde 
festgehalten. 


Darüber hinaus führt eine vollständige Protokollierung aller Ereignisse zu 
einem exponentiellen Wachstum des Speicherbedarfs im Worst-Case, sprich 
p € O(|Y|!¢!).! Selbst wenn man von atomaren Ereignissen ausgeht, von 
jedem Ereignis also nur ein Quellcontainer betroffen ist, liegt der Speicherbedarf 
in der Größenordnung von Y € O(|é| - |2|), wächst also linear. 


Aus diesem Grund wurde im letzten Kapitel die konzeptionelle Entscheidung 
getroffen, dass das Informationsfluss- und das Personal-Data-Provenance- 
Modell getrennt werden. Der Umfang der Protokollierung kann so gröber 
als der Detailgrad des Informationsfluss-Trackings festgelegt werden. Im 
Informationsflussmodell wird ausschließlich der aktuelle Zustand eines Systems 
und keine Historie abgebildet. Sein Speicherverbrauch kann deshalb nicht über 
die Menge der Zustände des laufenden Systems hinausgehen. Die Historie, die 


l Beispiel: Fork aller datenverarbeitender Prozesse bei jedem Ereignis. 
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einzig in der Provenance-Datenstruktur vorliegt, kann allerdings mit jedem 
weiteren Ereignis wachsen. Optimierungsversuche können sich deshalb auf die 
Größe der Provenance-Datenstruktur beschränken. 


Um sowohl der Datenminimierungsproblematik als auch der Speicherproblema- 
tik in der Provenance-Datenstruktur Herr zu werden, werden in diesem Kapitel 
zwei aufeinander aufbauende Ansätze vorgestellt. Abschnitt 7.1 stellt Lösch- 
regeln für eine zielgerichtete und datenminimale Personal-Data-Provenance 
vor. Im Abschnitt 7.2 wird das Konzept abstrakter Container als Teil des In- 
formationsflussmodells erläutert. Abstraktionsregeln erlauben, die Provenance 
bereits zum Entstehungszeitpunkt noch kompakter zu gestalten. Beide Ansätze 
werden in Abschnitt 7.3 evaluiert. 


7.1 Zielgerichtete und datenminimale 
Personal-Data-Provenance 


Von den in den technischen Anforderungen festgelegten Löschregeln (An- 
forderungen 24 ff.), sind nur die Regeln für Speicher- und Verarbeitungsre- 
präsentationen (Anforderungen 28 und 29) ausschließlich von den Speicher- 
und Verarbeitungsvorgängen selbst abhängig. Eine Verarbeitungsrepräsentation 
muss aus der Provenance gelöscht werden, sobald die Verarbeitung beendet 
ist. Gleiches gilt für eine Speicherrepräsentation und die Speicherung. Im 
gemäß dieser Anforderungen konzipierten Datenschutzauskunftssystem läuft 
dementsprechend beim Aufruf der Methode terminateRepresentation() einer 
Repräsentation! in der Provenance-Datenstruktur des ProSP ein Löschalgo- 
rithmus ab. 


Der Algorithmus operiert auf zwei Attributen der Repräsentation, dem 
predecessor und dem successorSet. Der predecessor ist der Vorgänger 
einer Repräsentation in der Baumstruktur des Provenance-Graphen. Das 
successorSet ist die Menge der Nachfolger.” Für alle anderen außer den oben 


! Vgl. Diagramm 6.1. 
? Vgl. auch Kapitel 6.4. 
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erwähnten Repräsentationen wird durch den Algorithmus nur der Terminie- 
rungszeitpunkt (terminationTime) gesetzt. Eine Speicher- oder Verarbeitungs- 
repräsentation wird dagegen aus dem Provenance-Graph entfernt. 


Dazu werden zunächst neue Kanten unter Umgehung der zu entfernenden 
Repräsentation gebildet. Die Nachfolger der Repräsentation werden zu den 
Nachfolgern ihres Vorgängers. Gleichzeitig wird ihr Vorgänger zum Vorgänger 
ihrer Nachfolger. Indem abschließend alle Kanten von und zu der Repräsentation 
gelöscht werden, ist die Repräsentation vollständig aus dem Provenance- 
Graphen ausgelöst. Der Speicherplatz wird freigegeben. 


7.2 Abstrakte Container und 
Abstraktionsregeln 


Das Recht auf Auskunft verpflichtet die verantwortliche Stelle nicht dazu, die 
Funktionalität ihrer IT-Systeme im Detail wiederzugeben. Datenflüsse in tech- 
nisch bedingten Systemprozessen sind gänzlich uninteressant.! Gleiches kann 
für Speicherorte gelten. Beispielsweise ist die Speicherung personenbezogener 
Daten in einer Kundendatenbank zu beauskunften, aber nicht, in welcher Zelle 
einer bestimmten Tabelle die Daten abgelegt sind. Auf der anderen Seite ist 
ein feingranulares Tracking personenbezogener Daten erforderlich, um nicht 
die Spur eines Datums zu verlieren oder dem Problem der Überapproximation 
zu erliegen.” Würde eine Datenbank insgesamt als Container aufgefasst und 
nur der Fluss von einer Datenbank in eine andere getrackt, müsste bei jedem 
dieser Flüsse angenommen werden, dass alle personenbezogenen Daten in der 
Datenbank geflossen sind. Datenschutzauskunftssysteme müssen so aufgebaut 
werden, dass sie mit diesen gegensätzlichen Anforderungen umgehen können. 
Ein Ansatz sind abstrakte Container. 


Abstrakte Container reduzieren den Detailgrad, in dem Provenance-Daten 
gesammelt werden. Sie fassen reale Container zusammen. Ein abstrakter 


! Beispielsweise von einer Windows-Explorer-Instanz in eine andere. 
? Lovat/Oudinet/Pretschner 2014. 
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Container vereint in sich alle Speicherfunktionen der zugrundeliegenden 
realen Container. Reale Container und abstrakte Container werden über eine 
unidirektionale Aliasrelation miteinander verbunden. 


Abstrakte Container optimieren die Sammlung von Provenance-Daten und 
weisen eine Reihe von Vorteilen gegenüber einer Selektion und Gruppierung 
realer Container zum Abfragezeitpunkt auf: 


e Reduzierung des Speicherbedarfs für Provenance-Daten: Für zugrun- 
deliegende reale Container werden keine eigenen Repräsentationen 
gespeichert. 


e Verbesserung der Laufzeit des Provenance-Systems: Die Anzahl der 
Methodenaufrufe auf dem ProSP ist deutlich niedriger. Objekterzeugung 
und Datenbankaufrufe fallen weg. 


e Datenvermeidung entsprechend der datenschutzrechtlichen Anforderun- 
gen wird umgesetzt: 


— Es werden nur die Datum-Realcontainer-Beziehungen des gegen- 
wartigen Systemzustandes gespeichert. 


— Es werden keine ergänzenden Parameter (z.B. Zeit) gespeichert. 


Als Beispiel für die Wirkweise abstrakter Container sollen die parallelisierten 
Prozesse in Multitasking-Betriebssystemen dienen. Die einzelnen Container 
der Teilprozesse! sind für die Datenschutzauskunft nicht von Interesse und 
werden auf einen abstrakten Container Prozesse abgebildet. Der abstrakte 
Container enthält alle Daten der Container der Teilprozesse. Jedes Mal, 
wenn die Speicherfunktion eines realen Containers modifiziert wird, wird 
auch die Speicherfunktion des abstrakten Containers aktualisiert. Bei einem 
Datenaustausch zwischen Teilprozessen würde sich jedoch die Gesamtsicht 
auf die Prozesse nicht verändern. Es fließt kein neues Datum in den abstrakten 
Container Prozesse. Seine Speicherfunktion ändert sich nicht. Ein neuer 
Provenance-Datensatz wird nicht erzeugt. 


! Der Container eines Prozesses bezeichnet den Speicherbereich im Hauptspeicher und im 
Hauptprozessor, den ein Prozess belegt. 
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Aus modelltheoretischer Sicht kann mit einem abstrakten Container genauso 
umgegangen werden, wie mit jedem anderen Container. Faktisch gibt es keinen 
direkten Bezug von Ereignissen auf abstrakte Container. Die Speicherfunktion 
abstrakter Container wird nur implizit über eine Aliasfunktion verändert. 


7.2.1 Abstraktionsregeln 


Welche realen Container durch welche abstrakten Container zusammengefasst 
werden, wird durch Abstraktionsregeln ausgedrückt. Abstraktionsregeln bilden 
anhand der Benennungsfunktion Äquivalenzklassen von realen Containern. 


Es ist notwendig, die Benennung von Containern hierarchisch auszudifferenzie- 
ren, um Abstraktionsregeln zu formulieren. Nur so kann ausgedrückt werden, 
auf welcher Ebene abstrahiert wird. 


Der ausdifferenzierte Bezeichner lautet F C Dom x LoA x Type x Hndl. 
Auf der obersten Ebene steht die lokale Domäne (Dom), in der sich ein 
Container befindet. Sie beschreibt auf der niedrigsten Hierarchieebene in 
der Regel ein konkretes IT-System. In einer Organisation bestimmt sie den 
lokalen Zuständigkeitsbereich der meisten Usage-Control- und Provenance- 
Komponenten.! Unterhalb der Domäne steht die Abstraktionsschicht (Layer 
of Abstraction, LoA). Sie beschreibt die Quelle der Ereignisse und damit den 
Zuständigkeitsbereich eines PEP. Häufig entspricht eine Abstraktionsschicht 
einer Applikation oder einem Element der Datenhaltung. Dadurch wird sie 
als Abgrenzungsmerkmal für Abstraktionsregeln interessant. Des Weiteren hat 
jeder Container einen Typ ( Type). Der Typ entspricht einer Container-Klasse, 
wie sie im Usage-Control-PSM-Modell definiert ist.” Ein Beispiel für einen 
Containertyp wäre File auf der Abstraktionsschicht eines Dateisystems. Letzter 
Bestandteil des Bezeichners ist der konkrete Identifikator (Hndl), mit dem ein 
einzelner Container in einer Abstraktionsschicht referenziert wird. Beispiele 


! Insbesondere des PDP, des PIP, des lokalen PMPs und des ProSP. Die Bezeichner der Usage- 
Control-Domänen werden in Anhang D beschrieben. 
2 Siehe Kumari/Pretschner 2013. 
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dafiir sind der Pfadname in einem Dateisystem oder der Window Handle auf 
Betriebssystemebene. 


Dom, LoA und Type sind fiir jeden Container eindeutig. Sprechen zwei unter- 
schiedliche IT-Systeme oder Abstraktionsschichten vom gleichen Container, 
wird dies durch eine bidirektionale Aliasbeziehung zwischen zwei im Modell 
getrennten Containern deutlich gemacht. Deshalb kann vereinfachend fiir die 
Benennungsfunktion eine komponentenweise Umkehrfunktion f; = pr; o f7! 
für i € { Dom, LoA, Type} mit der Projektion pr;(a1,...,Q@n) = a; angege- 
ben werden. 


Die erweiterte Benennungsfunktion erfüllt gleichzeitig die durch die Anforde- 
rungen 7, 9, 10, 11, 12 und 15 verlangte Protokollierung von Organisationsein- 
heit und IT-System sowie die von Anforderung 12 in Einzelfallen geforderte 
Angabe des Typs einer Anwendung. 


Aus der erweiterten Benennungsfunktion ergeben sich drei verschiedene 
Aquivalenzrelationen R auf der Menge der realen Container: 


e Die Domänenäquivalenz mit cı “Dom C2 € fDom(Cı) = foom(c2) 


e Die Abstraktionsschichtäquivalenz mit 
C1 ~LoA C2 © fDdom(c1) — Dom (e2) N froa(c1) = froa(C2) 


e die Typäquivalenz mit 
C1 “Type C2 = Dom (cı) = Dom (c2) N froalcı) = fioa(c2) N 
FType(cı) = Frype (ca) 


Eine Abstraktionsregel beschreibt, welche Aquivalenzklasse [c]r € P(%;caı) 
auf welchen abstrakten Container Cabstr € Cabstr abgebildet wird. Eine 
Abstraktionsregel ist durch einen Vertreter der Äquivalenzklasse, die Art der 
Äquivalenzrelation (Dom, LoA oder Type) und den referenzierten abstrakten 
Container vollständig charakterisiert. 


Abstraktionsregeln sind containerzentriert und nicht datenzentriert. Insofern ist 
es im Rahmen des Modells nicht möglich, für unterschiedlich sensible Daten 
den Detailgrad des Trackings zu variieren. 
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Algorithmus 12 zeigt, wie das Informationsflussmodell modifiziert wird, wenn 
eine Abstraktionsregel hinzugefügt wird. 


Algorithmus 12: add Abstraction(o, |C|R, Cabstr) 

ı (sl, f) 0 

2 forall u € [c]r do 

3 | Le lju + (u) U {cabstr}] 

4 end 

s (s,l, f) + update_abstr_container((s,l, f), Cabstr) 
6 return (s,/, f) 


Entsprechend stellt Algorithmus 13 die Veränderungen dar, die vorgenommen 
werden, wenn eine Abstraktionsregel wieder entfernt wird. Die Hilfsfunktion 
update_abstr_container wird in Algorithmus 14 beschrieben. Sie aktualisiert 
die Speicherfunktion für einen abstrakten Container anhand der auf diesen 
verweisenden Aliasbeziehungen. 


Algorithmus 13: rm Abstraction(o, [C]R, Cabstr) 


ı (sl, f) 0 

2 forall u € [c]r do 

3 | Le lju + I(u) \ {Cabstr}] 

4 end 

s (s,l, f) + update_abstr_container((s,1, f), Cabstr) 
6 return (s,/, f) 


Abstraktionsregeln, die auf ein Informationsflussmodell angewendet werden, 
dürfen je abstraktem Container nur disjunkte Aquivalenzklassen enthalten. Wür- 
den Überschneidungen auftreten, könnten Abstraktionsregeln nicht mehr unab- 
hängig von anderen Regeln entfernt werden (vgl. Zeile 3 in Algorithmus 13). 
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Nur wenn jeder reale Container ausschließlich in einer der Aquivalenzklassen 
auftaucht, bleiben die Vorgänger- und Nachfolgerbeziehungen bei Informati- 
onsflüssen erhalten. 


Abstraktionsregeln führen zu einer Ergänzung des Informationsflussmodells 
um die Speicher- und Aliasrelationen abstrakter Container. Es gehen keine 
Informationen verloren, die bereits ohne Abstraktionsregeln Teil des Informati- 
onsflussmodells sind. Abstraktionsregeln reduzieren ausschließlich die Anzahl 
der im Provenance-Modell zu speichernden Repräsentationen. 


Algorithmus 14: update_abstr_container (c, Cabstr) 
1 (8,1, f) 0 

28<- S[Cabstr = Ucec | Cabstr El(€) s(c)] 

3 return (s,/, f) 


7.2.2 Umsetzung der Abstraktionsregeln in der 
Implementierung 


Die Vorgabe, welche Abstraktionsregeln greifen, kann entweder global festge- 
legt oder in UC-Policies definiert sein. Da die Relevanz eines Containertyps, 
einer Abstraktionsschicht oder einer ganzen Domäne für den Auskunftsan- 
spruch nicht vom einzelnen Datum, sondern von generellen Überlegungen 
abhängig ist, sind Abstraktionsregeln nicht datenspezifisch. 


Abstraktionsregeln werden im PIP konfiguriert. Deshalb wird die Schnittstelle 
des PIP um die drei in Listing 7.1 gezeigten Methoden erweitert. Mit der 
ersten Methode lässt sich ein abstrakter Container, mit der zweiten eine 
Abstraktionsregel hinzufügen. Die dritte Methode entfernt Abstraktionsregeln. 
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boolean addAbstractContainer(AbstractContainer abstractContainer); 

Ruleld addAbstractionRule(String dom, String loa, String type, Containerld 
<> abstractContainer); 

boolean removeAbstractionRule(Ruleld rule); 


Listing 7.1: Schnittstelle des PIP fiir Abstraktionsregeln 


Beispiel. Eine Abstraktionsregel, die alle Prozesse auf einem 
Arbeitsplatzrechner zusammenfasst, wird durch die Domäne 
urn:ucn:adbokis:sales:workspace23, die Abstraktionsschicht 
os:process und den Typ process beschrieben. 


Die Primitive aus Kapitel 6.2 erfüllen bereits alle Voraussetzungen zur Verar- 
beitung abstrakter Container. Auch in der Verbindung von Informationsfluss- 
und Provenance-Modell in Kapitel 6.3.2 wurden abstrakte Container bereits 
berücksichtigt. Vom ProSP wird ein abstrakter Container wie jeder andere 
Container behandelt. 


7.3 Evaluation der Skalierbarkeit 


Zu Beginn dieses Kapitels wurde die Frage aufgeworfen, ob und wie ein 
skalierbares, insbesondere speicherskalierbares, Datenschutzauskunftssystem 
konstruiert werden kann. Angenommen wurde ein exponentielles Wachstum 
des Speicherbedarfs im Worst-Case. 


Die vorhergehenden Abschnitte haben zwei theoretische Konzepte zur Adres- 
sierung der Problemstellung eingeführt: Löschregeln und Abstraktionsregeln. 
Ohne eine Evaluation der Konzepte am realen System kann jedoch keine 
Aussage darüber getroffen werden, ob die Konzepte praktisch wirksam sind. 


In diesem Abschnitt werden der Aufbau und die Ergebnisse eines Lasttestes zur 
Evaluation der Laufzeit und des Speicherverbrauchs des Datenschutzauskunfts- 
systems vorgestellt. Sowohl Löschregeln als auch Abstraktionsregeln sollten 
sich aus konzeptioneller Sicht positiv auf den Speicherverbrauch des ProSP 
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auswirken. Bei den Abstraktionsregeln sind potentiell negative Auswirkungen 
auf den Speicherverbrauch des PIP méglich. 


Die Zielsetzung dieses Abschnitts ist, zu zeigen, dass (1) die Komponenten 
des Datenschutzauskunftssystems die Laufzeit der Verarbeitung personen- 
bezogener kaum beeinflussen (konstanter Faktor) und (2) Löschregeln und 
Abstraktionsregeln den Speicherbedarf des Datenschutzauskunftssystems im 
Verhältnis zur Menge der in jedem Schritt verarbeiteten personenbezogenen 
Daten maximal linear und im Verhältnis zur Menge der Operationen sublinear 
steigen lassen. 


7.3.1 Testaufbau und Konfiguration 


Im Lasttest zu obigen Konzepten werden sequentiell Dateien kopiert. Die 
Kopierereignisse auf Betriebssystemebene werden durch das Datenschutzaus- 
kunftssystem abgefangen. Sie werden durch den PIP und den ProSP verarbeitet 
und gespeichert. Der gemessene Speicherverbrauch der Komponenten lässt 
Rückschlüsse auf die Wirksamkeit der Löschregeln und Abstraktionsregeln zu. 
Eine Kopieroperation ist die einfachste Operation die alle drei Primitive der 
Speicherfunktion abdeckt. Welche Ereignisse dafür verantwortlich sind, wird 
weiter unten ausgeführt. 


Nach einer Erläuterung der verwendeten Hard- und Software werden im 
Folgenden der genaue Testablauf und die verwendeten Parameter und Modi 
dargestellt. 


Hardware und Betriebssystem Die Laufzeit des Datenschutzauskunftssys- 
tems und die Auswirkungen von Löschregeln und Abstraktionsregeln auf den 
Speicherverbrauch wurden auf einem System unter Microsoft Windows 7 x64 
mit einem Intel Core 17-4790 Prozessor @ 3,6 GHz und 8 GB Arbeitsspeicher 
getestet. Alle Hintergrundprozesse, die sich störend auf die Messungen auswir- 
ken könnten, wie beispielsweise der Update-Mechanismus des Betriebssystems, 
wurden deaktiviert. 
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Für die Messungen wurde auf Ereignisse des Betriebssystems zurückgegriffen. 
Der Vorteil gegenüber Ereignissen aus Applikationen ist, dass damit das 
gesamte Prozessgeschehen abgedeckt wird und die Messungen repräsentativ für 
eine Vielzahl von realen Einsatzszenarien eines Datenschutzauskunftssystems 
sind. Der wesentliche Nachteil ist, dass das Abfangen von Ereignissen auf 
Betriebssystemebene „teuer“ ist, also viel Rechenzeit kostet. Dies wirkt sich 
negativ auf die Gesamtlaufzeit der Tests aus. 


Verwendete Komponenten des Datenschutzauskunftssystems Grundlage 
des für Windows 7 verwendeten PEPs ist das Hooking-Framework von Wüch- 
ner.! Es setzt auf Deviare auf,” um sich in die Windows API einzuhingen.* 
Die Einbindung des Hooking-Frameworks in das Datenschutzauskunftssystem 
übernimmt ein ergänzend entwickelter Adapter. 


In den Tests standen die Komponenten PIP und ProSP im Mittelpunkt. Infor- 
mationsflüsse durch die folgenden Ereignisse sind Teil der Informationsflussse- 
mantik des Windows-PEP und werden überwacht: CreateProcess, KillProcess, 
CreateFile, CreateEmptyFile,* TruncateFile,” DeleteFile, MoveFile, CopyFile, 
ReadFile, WriteFile, CreateWindow, SetClipboardData, GetClipboardData, 
CreateDC,° Send und Recv.’ Alle anderen abgefangenen Ereignisse werden 
dem PIP zwar vom PEP mitgeteilt, sie werden jedoch nicht ausgewertet. Alle 
Komponenten des Datenschutzauskunftssystems stehen auf einer Whitelist. 
Die von ihnen verursachten Ereignisse werden vom PEP nicht weitergeleitet. 


Als weitere Komponenten kamen ein ProCP, ein PMP und ein PAP zum 
Einsatz. Ein PDP wurde nicht verwendet, da keine UC-Policies eingesetzt 
wurden. Das Provenance-Tracking wurde fiir jedes Datum direkt vom PAP 
aktiviert. Der PAP gab auBerdem dem PIP die Abstraktionsregeln vor. 


1 Wiichner/Pretschner 2012. 

2 http://www.nektra.com/products/deviare-api-hook- windows. 

3 kernel32.dll, user32.dll, Gdi32.dll und Ws2_32.dll. 

4 CreateFile mit dem Parameter dwCreationDisposition=CREATE_ALWAYS. 

5 CreateFile mit dem Parameter dwCreationDisposition-TRUNCATE_EXISTING. 
6 Ausgabe auf ein Gerät, z.B. einen Drucker. 

7 Send und Recv bezeichnen Zugriffe auf den Netzwerkstack von Windows. 
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Der ProCP lief auf demselben System wie die tibrigen Komponenten (lokale 
Konfiguration). Der ProCP wird nur beim Bekanntmachen neuer personenbe- 
zogener Daten aufgerufen und spielt im weiteren Verlauf der Erfassung von 
Informationsflüssen keine Rolle. Sein Einfluss auf die Laufzeit des Daten- 
schutzauskunftssystems ist somit minimal. Der Speicherbedarf des ProCP 
wächst im ungünstigsten Fall linear mit der Anzahl der berücksichtigten per- 
sonenbezogenen Daten. Er wurde deshalb im Experiment nicht gesondert 
betrachtet. 


Die Komponenten sind alle in Java implementiert und laufen dementsprechend 
in einer Java Virtual Machine (JVM). Der Garbage Collector der JVM führt zu 
instabilen Messungen des Speicherverbrauchs der Komponenten. Um diesen 
Effekt zu reduzieren, wurde der inkrementelle Garbage Collector (Parameter 
—Xincgc) aktiviert. Der inkrementelle Garbage Collector läuft dauerhaft parallel 
zur Programmausführung, während der reguläre Garbage Collector nur dann 
Speicher freigibt, wenn ein bestimmter Schwellwert des Speicherverbrauchs 
überschritten wurde. Da der Garbage Collector in einem eigenen Prozess 
läuft, sind die Auswirkungen des inkrementellen Garbage Collectors auf 
die gemessene Laufzeit des Datenschutzauskunftssystems im verwendeten 
Testsystem mit Mehrkernprozessor vernachlässigbar. 


Traces und Aktivitäten Von der entwickelten Testumgebung werden soge- 
nannte Traces ausgeführt. Ein Trace ist eine sequentielle Abfolge atomarer 
Aktivitäten, die ein Benutzer ausführen kann, wie beispielsweise der Aufruf 
eines Kommandozeilentools zum Kopieren von Dateien (Kopieroperation). 
Die Länge eines Traces wird durch die Testparameter bestimmt. Für die Last- 
tests wurden zwei Aktivitäten gewählt: CallPAP und CopyFile. Die Aktivität 
CopyFile ist nicht identisch mit dem Ereignis CopyFile der Windows-API, 
sondern ist in der Implementierung der Testumgebung ein Bash-Skript, das 
das Kommandozeilentool cp aufruft. ! 


! Verwendet werden die Bash und GNU cp als Teil von MSYS bzw. MinGW, http://mingw-w64.org. 
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Im einfachsten, für die Lasttests gewählten Fall wird CallPAP nur zu Beginn 
eines Traces ausgeführt. Das Testverzeichnis enthält zu Beginn nur eine Datei 
zufälligen Inhalts, deren Größe durch die Testparameter bestimmt wird. Die 
Aktivität CallPAP besteht aus genau einem Aufruf des PAP. Der PAP weist der 
initialen Datei (Container) eine durch die Testparameter vorgegebene Anzahl 
personenbezogener Daten zu.' Für jedes Datum wird das Provenance-Tracking 
aktiviert. 


Alle anderen Aktivitäten des Traces sind CopyFile-Aktivitäten. Die Parameter 
einer CopyFile-Aktivitat sind eine zufällige Datei im Testverzeichnis (zu Beginn 
die initiale Datei) als Quelle und eine neue Datei, in die die Quelle kopiert 
werden soll. Dateien werden somit niemals gelöscht oder überschrieben.” 


Ein Trace der Länge 5 würde aus den Aufrufen [CallPAP, CopyFile, CopyFile, 
CopyFile, CopyFile] bestehen. Jeder Aufruf von CopyFile führt zu einer Reihe 
nicht in Gänze deterministischer Ereignisse auf der Windows-API. Diese 
Ereignisse werden nachfolgend erläutert. 


Ereignisse von cp Bei jedem Aufruf von cp wird zuerst der cp-Prozess 
erzeugt. Dann wird aus einer zufälligen Datei im Testverzeichnis gelesen. 
Anschließend wird der Inhalt der Datei in eine neue Datei geschrieben. Zuletzt 
wird der cp-Prozess wieder beendet. Daraus ergeben sich für cp unter anderem 
die Ereignisse CreateProcess, KillProcess, CreateFile, ReadFile und WriteFile. 
Die Ereignisse decken die drei Primitive der Speicherfunktion ab,* die zu einer 
Modifikation der Provenance führen.” 


Ein personenbezogenes Datum wird unabhängig vom Inhalt der Datei als ID ausgedrückt 
(siehe Anhang D). Die Daten sind alle dem selben Betroffenen zugeordnet. Eine Zuweisung zu 
unterschiedlichen Betroffenen führt zu einmaligem konstantem Overhead je Betroffenem und 
spielt daher für die Aussage zur Last- und Speicherskalierbarkeit keine Rolle. 

Ein Überschreiben oder Löschen würde den Speicherbedarf von PIP und ProSP verringern. Dies 
ist im Lasttest unerwünscht. 

Bei den in der Auswertung genannten Längenangaben wird CallPAP ignoriert. Die Angabe 
„Tracelänge 800“ bedeutet also tatsächlich das 800-fache Ausführen von CopyFile und eine 
Länge des Traces von 801 incl. CallPAP. 

4 flow, flow_to_rtc und clear; vgl. die Informationsflusssemantik im Anhang E.4. 

5 Vgl. Kapitel 6.3.2. 


N 
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Der sequentielle Wechsel aus Erzeugung und Beendigung von cp-Prozessen 
sowie der Fluss von Daten aus Dateien in Prozesse und umgekehrt fiihren zu 
einer hohen Last fiir den PIP und den ProSP. Andere Arten von Ereignissen 
wiirden entweder gar keine Anderung des Informationsflussmodells verursachen 
oder ausschließlich den PIP belasten. Insofern ist der gewählte Lasttest zwar 
nicht repräsentativ für alle Vorgänge in datenverarbeitenden Systemen. Er 
stellt aber ein Hochlastszenario dar, das geeignet ist, die Skalierbarkeit des 
Datenschutzauskunftssystems zu überprüfen. 


Parameter und Modi Insgesamt sind bei den Lasttests drei Parameter zu 
berücksichtigen: (1) die Anzahl der personenbezogenen Daten in der initialen 
Datei, (2) die Tracelänge, also die Anzahl der Kopiervorgänge, und (3) die 
Größe der Datei. 


Jede betrachtete Konfiguration der Parameter wurde mindestens 30 Mal getestet. 
Die Boxplots in den Abbildungen dieses Abschnitts zeigen die beobachtete 
Schwankungsbreite der Ergebnisse. 


Die Testumgebung kennt 7 Modi: 
[0] Durchlauf des Traces ohne aktives Datenschutzauskunftssystem 
[1] das Hooking-Framework ist aktiv 
[2] der PEP mit integriertem Hooking-Framework ist aktiv 
[3] PEP, PMP und PIP sind aktiv 


[4] PEP, PMP, PIP, ProSP & ProCP sind aktiv — ProSP ohne Löschregeln 
und Abstraktionsregeln 


[5] PEP, PMP, PIP, ProSP & ProCP sind aktiv — ProSP mit Löschregeln 
und ohne Abstraktionsregeln 


[6] PEP, PMP, PIP, ProSP & ProCP sind aktiv — ProSP mit Löschregeln 
und Abstraktionsregeln für Prozesse (os:process/process) und Dateien 
(os:filesystem/file) 
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Modus 0 gibt die Vergleichswerte vor. Die Modi 1 und 2 sind in nahezu 
allen Aspekten äquivalent und zeigen die Laufzeitbeeinträchtigungen durch 
das Hooking-Framework. Modus 3 ist der Vergleichswert für eine reine UC- 
Infrastruktur. Die Modi 4 bis 6 liefern Vergleichsdaten für das komplette 
Datenschutzauskunftssystem, konfiguriert mit den verschiedenen, in diesem 
Kapitel vorgestellten, Möglichkeiten. 


7.3.2 Ergebnisse der Laufzeitmessungen 


Die Bewertung des Datenschutzauskunftssystems hängt von der verursachten 
Prozessorlast, überprüfbar anhand der Laufzeit eines Traces in den verschie- 
denen Modi, und vom Speicherbedarf des PIP und des ProSP ab. Fraglich 
ist, welche Faktoren Laufzeit und Speicherverbrauch bestimmen und ob die 
Komponenten des Datenschutzauskunftssystems in Dateigröße, Tracelänge 
und Anzahl der personenbezogenen Daten skalieren. In diesem Unterabschnitt 
wird zunächst die Laufzeit diskutiert. 


Dateigröße Zunächst ist festzustellen, dass bei großen Dateien der Aufwand 
für die eigentlichen Kopieroperation steigt. Dateigrößen von | KB bis 10000 KB 
führen im Modus 0 (nicht abgebildet) nur zu Laufzeiten zwischen 1 s und 5s. 
Bei einer Größe der initialen Datei von 100000 KB steigt die Laufzeit dagegen 
auf durchschnittlich 57 s an. Bei einer Tracelänge von 100 werden insgesamt 
10GB kopiert. 


Die Größe der initialen Datei hat unter anderem deshalb bis 1000 KB kaum 
Einfluss auf die Laufzeit eines Traces. Sehr große Dateien verlängern hingegen 
die Laufzeit (vgl. Abbildung 7.1). 


Die Schwelle zum Laufzeiteinfluss bei 1000 KB ist anhand einer Auswer- 
tung der vom Hooking-Framework abgefangenen Ereignisse erklärbar. Beim 
Sprung von 100KB auf 1 000 KB verändert sich die Anzahl der beobachteten 
Ereignisse. Bei 1 KB, 10 KB und 100KB und einer festen Tracelänge von 100 
werden jeweils im Durchschnitt 1 685 Ereignisse beobachtet. Bei 1000 KB 
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Abbildung 7.1: Laufzeit abhängig von der Größe der Datei (10 Daten, Tracelänge 100) 


steigt die Anzahl der Ereignisse auf 2 271. Bei 10 000 KB und 100 000 KB wer- 
den bereits 9 367 beziehungsweise 78 319 Ereignisse erreicht. Zum Kopieren 
einer Datei mit einer Größe von 1 000 KB werden also erstmals mehr Aufrufe 
der Windows-API erforderlich als für Operationen auf kleineren Dateien. 
Dies erklärt den in Modus 2 beobachteten deutlichen Anstieg der Laufzeit 
(vgl. Abbildung 7.1a). Das Hooking-Framework muss jedes einzelne Ereignis 
abfangen und an den PIP weiterleiten. Das Abfangen eines Ereignisses kostet 
Rechenzeit. 


Dagegen skalieren der PIP und der ProSP gut mit der Anzahl der zu verarbei- 
tenden Ereignisse. Selbst bei einer initialen Dateigröße von 100 000 KB steigt 
die Laufzeit im Modus 4 gegenüber dem Modus 2 nur um 8%. 


Sowohl im PIP als auch im ProSP haben die zusätzlichen Ereignisse keinen 
Einfluss auf die Datenstrukturen. Die stattfindenden Informationsflüsse werden 
mehrfach redundant detektiert. Bereits die ersten ReadFile- und WriteFile- 
Ereignisse beschreiben den Zustandsübergang der Speicherfunktion vollständig. 
Aus diesem Grund - und zugunsten einer effizienten Testdurchführung — wurde 
für die übrigen Tests eine Dateigröße von 100 KB gewählt. 
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Tracelänge Die Laufzeit eines Traces bewegt sich im Modus 0, abhängig von 
der Länge des Traces, zwischen 0 und 34 Sekunden. Die Schwankungsbreite 
ist allerdings im Vergleich zur Gesamtdauer groß. Die Laufzeit eines Traces 
der Länge 1000 schwankt selbst schon zwischen 15 und 34 Sekunden. 


Wird das Hooking-Framework zugeschaltet, steigt die Laufzeit der Traces um 
Größenordnungen (Abbildung 7.2b). Zusätzlich zur Ereignisverarbeitung bremst 
das Hooking eines jeden neuen Prozesses das Betriebssystem spürbar aus. Ein 
Trace mit etwa 78 300 Ereignissen und 100 neuen Prozessen (Dateigröße von 
1000 KB in Abbildung 7.1a) hat eine durchschnittliche Laufzeit von 790 s. 
Ein Trace mit etwa 16 800 Ereignissen und 1 000 neuen Prozessen (Tracelänge 
1 000 in Abbildung 7.2b) liegt bereits bei einer durchschnittlichen Laufzeit von 
5751s. Dies ist mehr als das Siebenfache. 


Mit Aktivierung des PEP, des PMP, des PIP, des ProSP und des ProCP steigt 
die Laufzeit in Relation zur Gesamtlaufzeit nur marginal (Abbildung 7.2c). 
Der Median der Laufzeit erhöht sich je nach Tracelänge um 1,5 bis 2 Prozent. 
Löschregeln und Abstraktionsregeln haben keinen nennenswerten Einfluss auf 
die Laufzeit eines Traces (Abbildung 7.2d). 


Über alle Modi hinweg verhält sich die Laufzeit der Traces linear proportional 
zur Länge des Traces (Abbildung 7.2b). Die verschiedenen Komponenten des 
Datenschutzauskunftssystems verlängern die Laufzeit nur um einen konstanten 
Faktor. Wie am Hooking-Framework für Windows 7 ersichtlich wird, hängt 
der Laufzeitoverhead des Datenschutzauskunftssystems im Wesentlichen von 
der Implementierung des Hooking-Teils des PEP ab. 


Anzahl personenbezogener Daten Wird statt der Tracelänge die Anzahl der 
personenbezogenen Daten in der initialen Datei variiert, stellt sich heraus, dass 
die Laufzeit eines Traces vollkommen unabhängig von diesem Parameter ist 
(Abbildungen 7.3a bis 7.3d). Die Anzahl neuer Prozesse und die Anzahl der zu 
verarbeitenden Ereignisse sind unabhängig von der Anzahl der personenbezo- 
genen Daten. Der Aufwand zur Modifikation der Datenstrukturen fällt nicht 
ins Gewicht. 
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Daraus folgt, dass das Datenschutzauskunftssystem ausreichend robust fiir den 
Einsatz in Datenverarbeitungsszenarien mit intensiver Nutzung personenbezo- 
gener Daten ist. Die Anwendung der Lésch- und Abstraktionsregeln ist auch 
bei einer Vielzahl personenbezogener Daten effizient durchführbar. 
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Abbildung 7.2: Laufzeit in Abhängigkeit von der Tracelänge (10 personenbezogene Daten, 100 KB 
Dateien) 
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Abbildung 7.3: Laufzeit in Abhängigkeit von der Anzahl der personenbezogenen Daten (Trace- 
länge 100, 100 KB Dateien) 
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7.3.3 Ergebnisse zur Speicherskalierbarkeit 


Der Speicherbedarf des Datenschutzauskunftssystems setzt sich aus dem Spei- 
cherbedarf des PIP fiir das Informationsflussmodell und dem Speicherbedarf 
des ProSP fiir die Provenance zusammen. Der Speicherbedarf des ProCP ist fiir 
jedes personenbezogene Datum konstant und damit unabhängig von den eigent- 
lichen Datenverarbeitungsvorgängen. In den Lasttests ist der Speicherbedarf 
des ProCP deshalb vernachlässigbar. 


Das Informationsflussmodell des PIP wächst mit jedem Ereignis, das die 
Speicher-, Alias- oder Benennungsfunktion um neue Relationen erweitert. Im 
gleichen Maße sinkt jedoch der Speicherbedarf des Informationsflussmodells, 
wenn Ereignisse Relationen aus der Speicher-, Alias- oder Benennungsfunktion 
entfernen (Primitive clear, rm_alias_locally, rm_alias_globally, clear_aliases, 
rm_bidir_alias_locally und rm_naming). Letzteres geschieht beispielsweise, 
wenn Prozesse beendet oder Dateien gelöscht werden. 


Für den Speicherbedarf des ProSP sieht die Situation anders aus. Die Proven- 
ance wächst mit jedem Informationsflussereignis. Die Historie vergisst in der 
Grundkonfiguration nichts. Der Umgang mit personenbezogenen Daten muss 
durchgängig nachvollziehbar sein (Anforderung 16). Löschregeln reduzieren 
potentiell den Speicherbedarf, indem Verarbeitungsschritte aus der Provenance 
entfernt werden, die abgeschlossen und für die Datenschutzauskunft nicht 
erforderlich sind. Abstraktionsregeln verhindern von Anfang an, dass das In- 
formationsflussmodell in vollem Detailgrad in die Provenance übertragen wird. 
Abstraktionsregeln werden im Informationsflussmodell über Aliasrelationen 
hinterlegt. Aus diesem Grunde erhöhen sie potentiell den Speicherbedarf des 
PIP. 


In den Abbildungen 7.4 bis 7.7 ist der zusätzliche Speicherbedarf der Kompo- 
nenten, der über den initialen Speicherverbrauch durch die Anwendungslogik 
der Komponenten hinaus auftritt, abhängig von den gewählten Parametern und 
Modi dargestellt. 
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PIP Betrachtet man den tatsächlichen Speicherbedarf des PIP, wird ersicht- 
lich, dass Abstraktionsregeln bei kurzen Tracelängen im Gesamtspeicherver- 
brauch des PIP untergehen. Unabhängig von der Anzahl der personenbezogenen 
Daten ist der Speicherverbrauch nach einem Trace der Länge 100 mit (Modus 
6) und ohne (Modus 4) Abstraktionsregeln fast identisch (Abbildung 7.5). Die 
für einen abstrakten Container in der Datenstruktur je Datum zusätzlich erfor- 
derliche Speicherrelation scheint nicht ins Gewicht zu fallen. Die notwendigen 
Aliasrelationen sind von der Anzahl der durch die Kopieroperationen berührten 
Container, und damit von der Tracelänge, abhängig. 


Bei längeren Traces steigt allerdings der Speicherbedarf des PIP (Abbildung 7.4). 
Jede Kopieroperation in eine neue Datei erfordert zwei neue Aliasrelationen, 
eine zum Container des Kopierprozesses und eine zum Dateicontainer. Der 
resultierende Speicherbedarf des Modus 6 bewegt sich jedoch in vergleichbaren 
Dimensionen wie der des Modus 4. Einflüsse des Garbage Collectors können 
nicht ausgeschlossen werden. 
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Abbildung 7.4: Speicherbedarf des PIP in Abhängigkeit von der Tracelänge (10 personenbezogene 
Daten, 100KB Dateien) 
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Abbildung 7.5: Speicherbedarf des PIP in Abhängigkeit von der Anzahl der personenbezogenen 
Daten (Tracelänge 100, 100 KB Dateien) 


ProSP Der Speicherbedarf des ProSP steigt ohne Lösch- und Abstraktions- 
regeln (Modus 4) sowohl linear mit der Tracelänge (Abbildung 7.6a) als auch 
linear mit der Anzahl der personenbezogenen Daten (Abbildung 7.7a). 


Mit Löschregeln (Modus 5) bleibt der Speicherverbrauch unverändert (Ab- 
bildungen 7.6b und 7.7b). Die Löschregeln sind wirkungslos. Einmal für die 
Provenance vergebener Speicher wird nicht wieder freigegeben, obwohl die Re- 
präsentationen der personenbezogenen Daten in den Kopierprozessen im Laufe 
eines Traces wieder aus der Datenstruktur entfernt werden. Der inkrementelle 
Garbage Collector ist entweder für diesen Anwendungsfall nicht leistungsfähig 
genug oder die Speicherfreigabe geschieht nur innerhalb des Prozesses der 
JVM und ist von Außen nicht sichtbar. 


Ganz anders stellt sich die Situation mit aktivierten Abstraktionsregeln dar 
(Modus 6). Eine Steigerung der Tracelänge führt zu keiner Veränderung des 
Speicherbedarfs der Provenance (Abbildung 7.6c). Der Speicherbedarf bleibt 
konstant, weil die Provenance nur bezüglich der beiden abstrakten Container, 
je einer für die Prozesse und einer für das Dateisystem, gespeichert wird. Die 
Kopieroperationen führen zu keinen neuen Einträgen in der Provenance. 
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Wird die Anzahl der personenbezogenen Daten erhöht, steigt der Speicherbe- 
darf auch weiterhin, jedoch um Größenordnungen weniger (Abbildungen 7.7c 
und 7.7d). Zusätzliche personenbezogene Daten erfordern zusätzliche Reprä- 
sentationen in der Provenance. In Abbildung 7.7d wird erkennbar, dass der 
Speicherbedarf sublinear steigt. 


Die Speicherskalierbarkeit des Datenschutzauskunftssystems wird durch die 
Abstraktionregeln signifikant verbessert. Der leichte Speichermehrbedarf im 
PIP wird durch die Speichereinsparungen im ProSP mehr als aufgewogen. 


7.4 Zwischenfazit 


Zwei Maßnahmen sollen zum datenminimalen und skalierbaren Einsatz des 
Datenschutzauskunftssystems beitragen: Löschregeln und Abstraktionsregeln. 
Konzeptionell führen diese Maßnahmen zu einer passgenauen Datensammlung 
und einer Provenance, die exakt dem durch den Auskunftsanspruch geforderten 
Umfang entspricht. 


Die vorliegende Evaluation wurde als Lasttest für Kopieroperationen durch- 
geführt. Kopieroperationen sind ein wesentlicher Faktor für den Austausch 
personenbezogener Daten. Sie decken die Primitive der Speicherfunktion 
im Informationsflussmodell vollständig ab. Kopieroperationen stellen ein 
Hochlastszenario für das Datenschutzauskunftssystem dar und testen das Da- 
tenschutzauskunftssystem in einer Extremsituation. Dennoch sind die Aussagen 
des Lasttests nicht generell auf beliebige andere Szenarien übertragbar. Bei- 
spielsweise könnten Ereignisse mit komplexeren Informationsflusssemantiken 
den Einfluss des PIP auf die Laufzeit des Systems erhöhen. 


Die Evaluation der Laufzeit des Datenschutzauskunftssystems zeigt, dass 
der Flaschenhals des Datenschutzauskunftssystems die PEPs sind. Sie haben 
den bedeutendsten Einfluss auf die Laufzeit des Systems. Mit dem Einsatz 
effizienterer Hooking-Mechanismen würde die Gesamtlaufzeit des Daten- 
schutzauskunftssystems merklich sinken. Der nahezu konstante Overhead der 
übrigen Komponenten des Datenschutzauskunftssystems lässt den Schluss 
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Abbildung 7.6: Speicherbedarf des ProSP in Abhängigkeit von der Tracelänge (10 personenbezo- 
gene Daten, 100KB Dateien) 


zu, dass das Datenschutzauskunftssystem an sich einem produktiven Einsatz 
gewachsen ist. 


Die Analyse des Speicherbedarfs des ProSP ergibt, dass Löschregeln bei der in 
Java vorgenommenen Implementierung keine Vorteile im Speicherverbrauch 
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(d) Modus 6 (Wertebereich bis 70 000 KB) 


Abbildung 7.7: Speicherbedarf des ProSP in Abhängigkeit von der Anzahl der personenbezogenen 
Daten (Tracelänge 100, 100 KB Dateien) 


ergeben. Löschregeln haben allerdings weiterhin dort ihre Berechtigung, wo 
Speicherorte in der Provenance persistiert werden müssen. Sie dienen dann 
dem Ziel der nachträglichen Datenminimierung. 
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Abstraktionsregeln haben in dem gegebenen Szenario stark positive Effekte. 
Die Größe der Provenance steigt im Verhältnis zur Menge der in jedem Schritt 
verarbeiteten personenbezogenen Daten sublinear und im Verhältnis zur Menge 
der Operationen gar nicht mehr. Es kann demnach bestätigt werden, dass eine 
datenminimale und skalierbare Implementierung von Provenance-Tracking 
möglich ist (93). 


Eine Einschränkung ergibt sich daraus, dass Abstraktionsregeln nur wirksam 
sein können, wenn ein hoher Abstraktionsgrad der Provenance akzeptabel 
ist. Werden einzelne Verarbeitungsschritte zu vollständig unterschiedlichen 
Zwecken durchgeführt, müssen diese Schritte in der Provenance erkennbar 
sein. Ein höherer Speicherbedarf ist dann die Folge. 
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Provenance-Tracking fiir ein Datenschutzauskunftssystem erfolgt in zweierlei 
Hinsicht verteilt: (1) Beim Austausch personenbezogener Daten zwischen 
unterschiedlichen Domänen und (2) bei der Speicherung und Aggregation von 
Personal-Data-Provenance. 


Der Austausch personenbezogener Daten zwischen unterschiedlichen Domä- 
nen ist als systemübergreifendes Informationsfluss- und Provenance-Tracking 
gestaltet. Nach einer Einführung in die Thematik werden im Abschnitt 8.1.1 
die notwendigen Erweiterungen der Informationsflusssemantik aus Kapitel 6.2 
behandelt.! Im anschließenden Abschnitt 8.1.2 wird der Ablauf des sys- 
temübergreifenden Provenance-Trackings dargestellt und an einem Beispiel 
erläutert. 


Die Konzepte zur Aggregation von Personal-Data-Provenance werden im 
Abschnitt 8.2 umrissen. Insbesondere wird die Rolle des ProCP und der Aufbau 
einer vollständigen Personal-Data-Provenance beleuchtet. 


8.1 Schichten- und systemübergreifendes 
Informationsfluss- und Provenance-Tracking 


Das im Kapitel 6.1 vorgestellte Informationsflussmodell unterstützt Infor- 
mationsflüsse innerhalb einer Abstraktionsschicht. Die PEPs der einzelnen 
Abstraktionsschichten können auf Grundlage dieses Modells die Semantik 
ihrer Ereignisse dynamisch beim zuständigen PIP hinterlegen. Das Modell ist 


l Die Ideen der Abschnitte wurden bereits in Birnstill/Bier et al. 2016 veröffentlicht. 
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allerdings noch nicht in der Lage, schichten- und systemiibergreifende Infor- 
mationsfliisse abzubilden. Schichtenübergreifende Informationsflüsse meint 
Informationsflüsse zwischen unterschiedlichen Abstraktionsschichten, z.B. 
dem Betriebssystem und einer Anwendung. Mit systemübergreifenden Infor- 
mationsflüssen werden Informationsflüsse zwischen IT-Systemen, die jeweils 
einen eigenen PDP, PIP und ProSP haben, bezeichnet. 


Bereits existierende Ansätze Ein Modell für schichtenübergreifende In- 
formationsflüsse wurde bereits von Lovat entworfen.! Dieses im Abschnitt 
8.1.1 beschriebene Modell wird in diesem Kapitel auf systemübergreifende 
Informationsflüsse verallgemeinert und einer Beschreibung in der Informa- 
tionsflusssemantik (siehe Kapitel 6.2) zugänglich gemacht. 


Ein Modell für Nutzungskontrolle in verteilten Systemen unter Berücksich- 
tigung von Informationsflüssen wurde von Kelbert entwickelt.” Kelbert legt 
einen starken Fokus auf die verteilte Auswertung und Durchsetzung von UC- 
Polices und auf die effiziente Kommunikation zwischen PDPs und PIPs. Das 
nachfolgend vorgestellte Modell für systemübergreifende Informationsflüsse 
übernimmt viele Ideen aus diesem Modell, unterscheidet sich allerdings in 
einigen wesentlichen Punkten. Kelberts Modell setzt einen Adressraum voraus, 
der eine Funktion von Adressen auf IT-Systeme bereitstellt. In der von Kelbert 
vorgestellten Instanziierung ist dies TCP/IP. Dieser Adressraum ist fest in die 
Implementierung integriert. Systemübergreifende Informationsflüsse werden, 
darauf aufbauend, anhand der TCP/IP-Verbindung identifiziert. 


Während alle gängigen Protokolle der Anwendungsschicht auf TCP/IP aufset- 
zen, ist es in der Praxis häufig nicht möglich, das Informationsfluss-Tracking 
direkt durch ein Monitoring des Netzwerk-Stacks durchzuführen. Eine Er- 
gänzung von Betriebssystemen um Komponenten eines automatisierten Da- 
tenschutzes wird zwar bereits seit Jahren gefordert,’ ist jedoch gegenwärtig 
noch nicht Realität. Deshalb ist es für Geschäftsanwendungen erstrebenswert, 


l Lovat 2015. 
2 Kelbert/Pretschner 2013; Kelbert/Pretschner 2014; Kelbert/Pretschner 2015. 
3 Wächter, DuD 1996, 272 (272). 
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PEPs als Plug-Ins in Applikationen zu integrieren, um nicht ins Betriebssystem 
eingreifen zu miissen. 


Das im Folgenden vorgestellte Modell erlaubt systemiibergreifendes Infor- 
mationsflusstracking auf Anwendungsebene. Die Verkniipfung der Informati- 
onsfliisse in den Anwendungen erfolgt dynamisch anhand der Informations- 
flusssemantik, die auf eine beliebige Kennung (Scope) verweist. Eine feste 
Implementierung im PIP ist nicht notwendig. 


Die Architektur von Kelbert erlaubt die Synchronisierung der Zustände in den 
Policy-Mechanismen (PDP) und des Zustands des Informationsflussmodels 
(PIP). Implementierungsseitig wird dafür eine verteiltes Apache-Cassandra- 
Datenbanksystem? verwendet. Da verteilte Nutzungskontrollentscheidungen 
für Data-Provenance und die Betroffenenrechte nicht erforderlich sind, werden 
sie von der hier vorgestellten Architektur nicht unterstützt. Ein IT-System wirkt 
für den PIP eines anderes IT-Systems wie ein PEP. Ein globaler Zustand über 
alle Datennutzungen würde dem Prinzip der informationellen Gewaltenteilung 
zuwiderlaufen.* 


Neben dem Ansatz von Kelbert existieren noch eine Reihe von Konzepten zur 
Propagierung von Taintmarken über Systemgrenzen hinweg. SeeC speichert 
je Prozess eines IT-Systems Taintmarken in einem Schattenspeicher und er- 
zeugt für jeden Socket eine write queue für Taintmarken zu Datenflüssen über 
TCP/IP.* NEON ist ein Monitor für virtuelle Maschinen und unterstützt Taint- 
marken zum Tracken von Informationsflüssen auf Byteebene.” Muniswamy- 
Reddy et al. integrieren in ihrem Framework Provenance-Collection und 
-Storage über Systemschichten hinweg.® Gleiches erlaubt GARM mit Hilfe 
von Application-Rewriting. ’ 


! In der Implementierung von Kelbert ist generell ein bidirektionaler Alias zwischen lokalem 
Socket und Remote-Socket vorgesehen. 

? http://cassandra.apache.org. 

3 In Cassandra haben dagegen alle Knoten dieselbe Rolle und damit gleichberechtigte Zugriffsrechte 
auf die gesamte verteilte Datenbank. 

* Kim et al. 2009. 

5 Q. Zhang et al. 2010. 

6 Muniswamy-Reddy et al. 2009. 

7 Demsky 2009; Demsky 2011. 


205 


8 Verteiltes Provenance-Tracking 


Motivation einer Erweiterung des Informationsflussmodells Sowohl bei 
schichten- als auch bei systemübergreifenden Informationsflüssen gibt es 
für jedes Ereignis, das einen ausgehenden Informationsfluss anzeigt (ausge- 
hendes Ereignis), ein korrespondierendes Ereignis, das einen eingehenden 
Informationsfluss signalisiert (eingehendes Ereignis). Diese beiden Ereignisse 
müssen durch die Semantik in Deckung gebracht werden, um eine durchgängige 
Provenance zu gewährleisten. 


Beispiel. /m Online-Shopsystem von Adbokis sind die Kundenstammdaten 
sowie die Daten zu allen vorangegangen Bestellungen hinterlegt. Das Backend 
des Shopsystems ist intern per Webbrowser erreichbar. Es lässt einen Export 
und Download der Kundenstammdaten durch Mitarbeiter von Adbokis zu. 
Werden Kundenstammdaten exportiert, muss der Zweckbezug und die Herkunft 
der Daten erkennbar bleiben. 


Sowohl auf Senderseite als auch auf Empfängerseite müssen in den Anwen- 
dungen, dem Shopsystem bzw. dem Browser, PEPs als Plug-Ins integriert 
sein, die die eingehenden beziehungsweise ausgehenden Ereignisse abfangen 
können. Prototypisch wurden Plug-Ins für das Online-Shopsystem Shopware! 
und den Browser Chrome? in PHP bzw. JavaScript implementiert. Darüber 
hinaus muss auf beiden Systemen eine vollständige lokale Infrastruktur des 
Datenschutzauskunftssystems bereitstehen. 


Der PEP des Shopsystems beobachtet nun zunächst ein Ereignis, das den Start 
eines Downloads signalisiert. Ein Download ergibt einen Informationsfluss 
von einem lokalen Datenobjekt hin zu einem Container, der die Download- 
verbindung verkörpert. Das Startereignis wird dem PIP mitgeteilt. Ohne eine 
Erweiterung des Modells würde der PIP das Ereignis nicht besonders interpretie- 
ren und die Downloadverbindung wie jeden anderen Container behandeln. Das 
empfangende System würde nicht informiert, die Provenance an dieser Stelle 
unterbrochen. Das auf Clientseite beobachtete Downloadereignis hätte folglich 


' https://de.shopware.com. 
? https://www.google.com/chrome. 
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keine Datenflüsse zur Folge. Zur Erkennung und Verarbeitung systemübergrei- 
fender Informationsflüsse ist es deshalb erforderlich, dass die Ereignisse auf 
beiden Seiten durch die PIPs gemäß einer (Remote-)Informationsflusssemantik 
interpretiert werden. 


8.1.1 Scope-Spezifikation und Scope-Verarbeitung 


Der Scope ist eine Kennzeichnung, die auf allen am Informationsfluss beteiligten 
Schichten oder Systemen bekannt ist. Eine Scope-Spezifikation kennzeichnet 
innerhalb einer Informationsflusssemantik, ob und in welcher Weise ein 
Ereignis zu einem Informationsfluss zwischen Abstraktionsschichten oder 
IT-Systemen gehört. Die Ereignisse, die zum selben Informationsfluss gehören, 
werden anhand des Scopes, gegeben in einem Parameter der Ereignisse, ein und 
demselben Informationsfluss zugeordnet. Der Parameter des Ereignisses kann 
auf unterschiedlichen Schichten allerdings durchaus unterschiedlich heißen. 
Die Zuordnung wird durch den Scopenamen in der Semantik sichergestellt. 


Das Informationsflussmodell wird demgemäß um eine Menge von Scopes 
SCOPE und Intermediate-Containern ©, erweitert. Ein Intermediate- 
Container (c, € @,) steht für eine bestimmte Verbindung zwischen zwei Schich- 
ten oder IT-Systemen. Intermediate-Container unterschiedlicher IT-Systeme 
sind nicht identisch, selbst wenn sie sich auf denselben Scope (ş € SCOPE) 
beziehen. Jedes Ereignis gehört zu maximal einem schichtenübergreifenden 
oder systemübergreifenden Scope. Der Zustand wird außerdem um die fol- 
genden beiden Abbildungen ergänzt:! Die Intermediate-Container-Funktion 
t: SCOPE — ©, bildet jeden Scope auf einen Intermediate-Container ab. Die 
Scope-Zustandsfunktion Ç : SCOPE — {activated, deactivated} bezeichnet 
die gegenwärtig aktiven, d.h. geöffneten, Scopes. 


Insgesamt ergibt sich ein Zustand © = (€ > P(2))x (€ > P(@)) x (F > 
C) x (SCOPE > @,) x (SCOPE — {activated, deactivated}). Im initialen 


I Lovat 2015. 


207 


8 Verteiltes Provenance-Tracking 


Systemzustand oo gibt es einen Intermediate-Container c, für jeden Scope s 
und ¢(s) ist deactivated für alle s € SCOPE. 


Drei Attribute einer Scope-Attributspezifikation in der Informationsflussse- 
mantik definieren, wie der der Systemzustand von einem Ereignis modifiziert 
wird: 


yx: © x E— SCOPE x DELIMITER x BEHAVIOR x INTER 
DELIMITER = {open, close, none} 

BEHAVIOR = {in, out, intra} 

INTER = {xlayer, xsystem} 


Der delim € DELIMITER gibt an, ob ein Ereignis einen neuen Infor- 
mationfluss einleitet. Ist der Delimiter open, dann ändert sich der Zustand 
des Scopes auf activated. Ist der Delimiter close, dann ändert sich der Zu- 
stand des Scopes auf deactivated. Bei none ändert sich nichts. Das Verhalten 
behav € BEHAVIOR beschreibt, ob ein Ereignis einen ausgehenden Fluss 
(out) oder einen eingehenden Fluss aus einer anderen Abstraktionsschicht oder 
einem anderen System (in) signalisiert. Das Verhalten eines Ereignisses be- 
einflusst die Verarbeitung der generischen Primitive in der Übergangsrelation. 
intra bedeutet, dass das Ereignis zu keinem übergreifenden Informationsfluss 
gehört. In diesem Fall hat das Ereignis keinen Scope! oder Delimiter. Die 
Primitive werden nicht modifiziert. inter € INTER unterscheidet zwischen 
schichtenübergreifenden (xlayer) und systemübergreifenden (xsystem) Infor- 
mationsflüssen. Das XML-Schema in Anhang E.1 berücksichtigt bereits all 
diese Aspekte. 


Wie in obiger Gleichung sichtbar, ist die Funktion x nicht nur vom Ereignis, 
sondern auch vom aktuellen Zustand des Informationsflussmodells abhängig. 
Deshalb müssen die Scope-Attribute zur Laufzeit anhand der Informationsfluss- 
semantik identifiziert werden. Die Aktionsbeschreibung eines Ereignisses in 
der Semantik beinhaltet die möglichen Scope-Attributspezifikationen für dieses 
Ereignis in einer geordneten Liste. Scope-Attributspezifikationen beinhalten, 


! Abbildung auf nil. 
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außer fiir behavior="INTRA", einen Scopenamen, der auf den Ereignisparameter 


verweist, der den Scope enthält. 


Algorithmus 15: Zinter(Z, 0, e) 

1 (ş, delim, behav, inter) + x(a, e) 
2 (s,1 
3 if s ~ nil then 


er 


¢[s < activated]) 


[s[e + s(c) U {di}i<i<nen] 


= sl, = s(c,) U {di}i<i<nen]] 


[Vu € l(c) : s[u = s(u) U {di}i<i<nen] 


Uc) : sju + s(u) U {di}i<i<nen]] 
[Vu € l* (c) : sue s(u) U {di }i<icnen] 


I*(c,) :s[u + s(u) U {d;}ı<i<nen]]| 


EG + s(c) U {di}i<i<nen] 


== > slc + s(c) U s(c.)]] 


[vu E l(c) : s[u + s(u) U {di}i<i<nen] 
l(c) : s[u + s(u) U s(c,)]] 


[vu E€ l” (c) : sju 4+ s(u) U {di}i<i<nen] 
I*(c): s[u — s(u) U s(c,)]] 


a + (s[e, + Ø], l, f, ı, ¢[y + deactivated]) 


4 c + Us) 

5 Trod I 

6 if delim = open then 

7 o + (s,l, f,ı, 

8 if behav = out A inter = xlayer then 

9 Fiod = Snia 
subst. 

10 

11 Fuad = Tmod 
subst. 

12 => Vue 

13 Taod — Tmod 
subst. 

14 => Vue 

15 if behav = in A inter = xlayer then 

16 Tod S Tod 
subst. 

17 

18 Tmod = Tod 
subst. 

19 => Vue 

20 Faod = Tmod 
subst. 

21 ==> Vue 

22 a+ Fmod(0, €) 

23 if delim = close then 

24 (5,1, f,4,¢) co 

25 

26 else 

27 a+ J (o,e) 

28 return o 
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Der PIP priift bei der Verarbeitung eines Ereignisses in der durch die Aktions- 
beschreibung gegebenen Reihenfolge die folgenden drei Bedingungen: 


1. Falls vorhanden, stimmt der Scopename mit dem Namen eines Parameters 
des Ereignisses tiberein? 


2. Falls die Scope-Attributspezifikation delimiter="OPEN" vorsieht, ist der 
in diesem Parameter referenzierte Scope deactivated? 


3. Falls die Scope-Attributspezifikation delimiter="NONE" oder 
delimiter="CLOSE" vorsieht, ist der in diesem Parameter referen- 
zierte Scope activated? 


Treffen alle Bedingungen zu, wird die entsprechende Scope-Attribut- 
spezifikation ausgewählt, die Attribute werden ausgelesen und die Uber- 
gangsrelation wird auf deren Grundlage modifiziert. 


Algorithmus 15 beschreibt, wie die Übergangsrelation Z modifiziert wird, 
um Ynod, die Übergangsrelation für xlayer- und xsystem-Informationsflüsse, 
zu erzeugen. J [links BIN rechts] bedeutet, dass der Term von 7 auf der 


linken Seite durch den Term auf der rechten Seite ersetzt wird. 


Zunächst wird geprüft, ob überhaupt ein Scope vorliegt (Zeile 3). Ohne einen 
Scope wird die Übergangsrelation nicht modifiziert. Falls der Delimiter open 
ist, wird der Scope aktiviert (Zeile 6). Ist der Delimitier close wird der Scope 
nach Abarbeitung des Ereignisses geschlossen (Zeile 23). Dazwischen wird 
abhängig vom Verhalten entweder das linke (Quelle, Zeile 15 ff.) oder das 
rechte (Ziel, Zeile 8 ff.) Argument der Primitve der Speicherfunktion durch 
den Intermediate-Container des Scopes ersetzt. 7,04 wird zum Abschluss auf 
den Zustand o angewandt (Zeile 22). Der Zustandsübergang ist vollzogen. 


Ein inter = xsystem führt zu keiner Modifikation der Übergangsrelation. 
Stattdessen löst es aus, dass der PIP dem PIP des anderen Systems eine spe- 
zielle Semantik, die Remote-Semantik weiterleitet. Diese Semantik lässt den 
Informationsfluss auf Empfängerseite wie einen schichtübergreifenden Infor- 
mationsfluss behandeln. Entsprechende Modifikationen werden vorgenommen. 
Die Details werden im nachfolgenden Beispiel behandelt. 
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8.1.2 Systemiibergreifende Informationsflüsse 


Zur Verarbeitung eines systemübergreifenden Informationsflusses gehören vier 
Schritte: (1) Benachrichtigung der empfangenden Seite über die Behandlung 
der fließenden Daten, (2) Verarbeitung des ausgehenden Informationsflusses auf 
Sender und Empfängerseite, (3) Verarbeitung des eingehenden Informations- 
flusses auf Empfängerseite und (4) Abschluss der Informationsflussbeziehung. 


PEP A PDP A PXPA PIP A 


notify(event) 


— 


representationRefimesData(cont, data) 


execute(deployPolicy, event) 


— 


Abbildung 8.1: Systemübergreifendes Usage-Control (1) 


Der erste Schritt beginnt damit, dass der PEP des sendenden IT-Systems 
(PEP A in Abbildung 8.1; Bsp.: Shopware-PEP) dem PDP seines Systems 
(PDP A) das Ereignis des beginnenden ausgehenden Informationsflusses mitteilt 
(downloadFile_start) und das Stattfinden des Ereignisses zunächst blockiert. 
Für jede Policy im PDP, die dieses Ereignis als Auslöser enthält, fragt der 
PDP beim PIP über die Methode representationRefinesData() anhand des 
Ausgangscontainers ab, ob das in der Policy referenzierte Datum von diesem 
Ereignis betroffen ist. Jede Tracking-Policy, für die das der Fall ist (Bsp.: 
Alle Policies für die Daten aus dem Kundendatensatz), löst die ExecuteAction 
deployPolicy aus. 
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PXPA PMP A PMP Master PMP B 
| 


retrievePolicy(policyID) 


| 
| 

policyTemplate 
E------°- 2222-2 | 
| 
| 
| 


deployPolicyTemplate(dom, policyTemplate) 


lookupPMP(dom) 


deployPolicyTemplate(dom, policyTemplate) 


policyID 


policyID 


Abbildung 8.2: Systemiibergreifendes Usage-Control (2) 


Im Folgenden wird o. B. d. A. nur von einem Datum ausgegangen. Der PXP! 
bezieht das in der Policy referenzierte Policy-Template fiir dieses Datum vom 
PMP/PRP (Abbildung 8.2). AnschlieBend wird das Policy-Template auf dem 
PMP des Empfängersystems (PMP B) abgelegt. Dazu wird der lokale PMP 
(PMP A) über die Methode deployPolicyTemplate() instruiert. Anhand der 
übergebenen Domäne (dom) wird beim Root-PMP? der empfangende PMP 
abgefragt (lookupPMP()) und dort dieselbe Deployment-Methode aufgerufen. 


Ist das Template auf dem Empfängersystem hinterlegt, wird es mit der ID des 
fließenden Datums instanziiert (Abbildung 8.3).Neben der ID des Datums wird 
die ID des Templates zweifach übergeben. Einmal, um auf das Template zu 
verweisen, das instanziiert werden soll (templatelD) und einmal als eine ID, die 
zur Instanziierung in das Template geschrieben werden soll (policyID). Dadurch 
kann das Template auch bei Auswertung der neu entstandenen Policy auf 
Empfängerseite für einen weiteren Informationsfluss wiedergefunden werden. 


Damit ist der erste Schritt abgeschlossen. Der PDP gibt die Entscheidung 
zurück, dass der Informationsfluss stattfinden darf. 


! Im Allgemeinen implementiert der PMP die entsprechende ExecuteAction. 
? Vgl. Kapitel 5.3.1 
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Systemiibergreifendes Usage-Control (3) 


Abbildung 8.3 
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Wird Provenance-Tracking nicht auf Basis von Tracking-Policies betrieben, 


sondern dauerhaft in allen PIPs aktiviert, entfällt der erste Schritt vollständig. 
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Abbildung 8.4: Systemiibergreifende Informationsfliisse (1) 
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Im zweiten Schritt wird zunächst der PIP der Senderseite (A) vom PEP über 
den nun zugelassenen Informationsfluss informiert (Abbildung 8.4, lookup- 
Aufrufe beim PMP sind zur Vereinfachung nicht dargestellt). Das Ereignis 
(Listing 8.1) wird auf Grundlage der bekannten Informationsflusssemantik des 
PEP (Listing E.1) durch den PIP interpretiert. 


Die Semantik des Ereignisses gibt einen systemübergreifenden Informati- 
onsfluss vor (behavior="OUT" delimiter="OPEN" intersystem="TRUE"). Dies 
bedeutet, dass das Ereignis auf Senderseite konventionell, das heißt ohne die 
Anwendung der Modifikationen in Algorithmus 15, verarbeitet wird. Der Scope 
wird allerdings aktiviert. 


<event action="downloadFile_start" timestamp="2016—07—10T21:45:00"> 
<complexParameter name="network"> 
<parameter name="domain" value="urn:ucn:adbokis:sales:online"> 
<parameter name="loa" value="app:shopware"> 
<parameter name="type" value="net"> 
<parameter name="name" 
— value="192.168.10.7:80;192.168.10.9:6927"> 
</complexParameter> 
<parameter name="network_name" 
— value="192.168.10.7:80;192.168.10.9:6927"> 
<parameter name="applicationObject_name" 
— value="cdb_connect_475908"> 
<parameter name="URL" 
— value="http://192.168.10.7:80/shopware/download/export.csv"> 
</event> 


Listing 8.1: Ereignis zum Start des Downloads beim Shopware-PEP 


Im Informationsflussmodell wird der Verbindung ein Bezeichner zur späteren 
Referenzierung zugewiesen (NF_ADD_NAMING). Anschließend werden der 
Speicherfunktion des Netzwerk-Containers alle Daten zugewiesen, die sich 
zuvor im für den Download zuständigen Verarbeitungsobjekt von Shopware 
befunden haben (SF_FLOW). 
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Des Weiteren wird der ProSP der Senderseite tiber den Informationsfluss infor- 
miert. Für jedes Datum wird die Provenance aktualisiert. Eine Repräsentation 
der Netzwerkverbindung wird mit der Repräsentation im Verarbeitungsobjekt 
als Vorgänger erzeugt. Da es sich um einen systemübergreifenden Informations- 
fluss handelt, wird außerdem der ProSP der Gegenstelle (ProSP B) über die neue 
Repräsentation in Kenntnis gesetzt. Die Repräsentation wird ohne gesetztes 
Vorgängerattribut übertragen, so dass auf Empfängerseite keine direkte Verbin- 
dung zur Provenance auf Senderseite besteht. Um die gesamte Provenance im 
Nachhinein herstellen zu können, wird in der CommunicationRepresentation 
auf beiden Seiten das Attribut remote mit der Domäne der jeweiligen Gegen- 
stelle gesetzt (vgl. Abbildung 6.1). 


Anschließend macht der PIP der Senderseite dem PIP der Empfängerseite die 
Speicherfunktion des Netzwerkcontainers bekannt. Dies geschieht über Aufrufe 
der Funktion setNewRespresentation(). Über diesen Vorgang wird auch der 
ProSP B vom PIP B informiert. Da die jeweiligen Repräsentationen bereits 
bekannt sind, findet keine Veränderung der Provenance auf Empfängerseite 
statt. 


In der Folge leitet PIP A das unveränderte Ereignis (downloadFile_start). 
an den PIP B weiter. Ist das weiterzuleitende Ereignis das erste Ereig- 
nis dieser Art, registriert der PIP A stellvertretend für den PEP A die 
Remote-Informationsflusssemantik des Ereignisses beim PIP B. Vom PIP B 
wird das Ereignis nun anhand der Remote-Informationsflusssemantik (Lis- 
ting E.2) interpretiert. Für die Empfängerseite ist ein systemiibergreifender 
Informationsfluss äquivalent mit einem von der Transportschicht eingehen- 
den schichtenübergreifenden Informationsfluss. Deshalb sind die Operanden 
des Primitivs SF_FLOW in der Remote-Informationsflusssemantik getauscht. 
Nach Anwendung der Scope-Semantik (behavior="OUT" delimiter="OPEN" 
<> intersystem="FALSE") findet der Fluss aus dem Netzwerk-Container in 
den Intermediate-Container des Scopes statt (Zeile 15 in Algorithmus 15). 
Dieser Informationsfluss wird auch dem ProSP mitgeteilt und führt zu einer 
entsprechenden Aktualisierung der Provenance. 
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Der Scope ist nun auf Sender- und auf Empfängerseite geöffnet. Ein erster 


Informationsfluss hat stattgefunden. Weitere könnten im Rahmen des selben 


Scopes folgen. Allerdings ist dies für den einzelnen Download nicht notwendig. 


Für alle Daten 


PEP B 


PDPB 


PIPB 


notifyEvent(event) 


create Representation() 


registerPEP(ifSemdntic) 


true 


BEE na a i ee en mS ed etna Sh ate a 


Für alle Daten 


ProSP B 


Abbildung 8.5: Systemübergreifende Informationsflüsse (2) 
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Am Ende des zweiten Schrittes hebt der senderseitige PEP die Blockade auf 
dem Ereignis in der Abstraktionsschicht auf und der Informationsfluss findet 
tatsächlich statt. 


Im dritten Schritt findet das duale Ereignis zum ausgehenden Informati- 
onsfluss statt: Der PEP der Empfängerseite (PEP B) fängt den eingehenden 
Informationsfluss ab (Abbildung 8.5). Das Ereignis wird zunächst an den PDP 
weitergegeben und dort ohne weitere Konsequenzen ausgewertet. 


Im Anschluss erhält der PIP B die Mitteilung über das Ereignis (notifyEvent()) 
und interpretiert das Ereignis (onCreated) anhand der Informationsflussse- 
mantik des Browsers (im Beispiel die des Chrome-Download-Managers, 
Listing E.3). Da der Scope bereits von der Senderseite geöffnet wur- 
de (behavior="IN" delimiter="NONE"), findet der Informationsfluss aus dem 
Intermediate-Container des Scopes in den downloadltem-Container des Brow- 
sers statt (SF_FLOW). Entsprechend wird die Provenance im ProSP aktualisiert. 


Im vierten und letzten Schritt erhält der PIP der Senderseite vom 
PEP die Information (Abbildung 8.6), dass der Download beendet wurde 
(downloadFile_end-Ereignis). Das Ereignis wird auch an den PIP B weiterge- 
geben. Auf beiden Seiten wird gemäß der (Remote-)Informationsflusssemantik 
die Speicherfunktion des Netzwerk-Containers im Informationsflussmodell 
geleert (SF_CLEAR) und der zum Container gehörende Bezeichner entfernt 
(NF_RM_NAMING). Entsprechend wird die Repräsentation im Provenance- 
Modell auch auf Sender- und Empfängerseite als terminiert gekennzeichnet. Auf 
der Empfängerseite wird außerdem der Scope geschlossen (behavior="OUT" 

— delimiter="CLOSE" intersystem="FALSE") . Daraus folgt eine Bereinigung 
des Intermediate-Containers im Informationsflussmodell. Die Repräsentatio- 
nen des Intermediate-Containers werden nicht weiter benötigt und aus der 
Provenance entfernt. 


Anstelle einer Schließung des Scopes von einem Kommunikationspartner aus, 
kann, sofern die Verbindung unkontrolliert abgebaut wurde, der Scope auch 
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von jeder Seite einzeln geschlossen werden. In der Semantik miisste dafiir 
jeweils ein gleichlautender „Intra-Close“ hinterlegt werden. 
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Abbildung 8.6: Systemiibergreifende Informationsfliisse (3) 
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8.2 Aggregation verteilter 
Personal-Data-Provenance 


Provenance 
Collection 


IF Tracking & 
Provenance Storage 


ee SENSES Provenance : D oy acy 
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Abbildung 8.7: Aggregation verteilter Personal-Data-Provenance 


Die Personal-Data-Provenance wird über alle Systeme verteilt gespeichert. 
Jeder ProSP hält in Übereinstimmung mit Anforderung 20 nur genau die Teile 
der Provenance vor, die sich auf Ereignisse der Domäne, die er verantwortet, 
beziehen. Ferner wird aus dem gleichen Grund bei systemübergreifenden 
Informationsflüssen, mit Ausnahme einer Repräsentation, keine Provenance 
ausgetauscht (Schritt 2 in Abschnitt 8.1.2). 


Der ProCP, als für die Aggregation verantwortliche Komponente der Ar- 
chitektur, wird nur zum Erhebungszeitpunkt involviert (Anforderung 21). 
Er erhält Informationen zum Betroffenen und der Domäne der erheben- 
den Stelle (Kapitel 5.3.2). Dies ist auch der Einstiegspunkt der Aggregati- 
on: Über die Methode getProvenanceOfData() ruft der ProCP beim ProSP 
des erhebenden Systems den ersten Teil der Provenance, die Wurzel des 
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Provenance-Baums, ab. Diesen Provenance-Abschnitt durchsucht der ProCP 
nach Communication-Repräsentationen. Anhand der in diesen Repräsentatio- 
nen verzeichneten Remote-Domänen kann der ProCP die nächsten Abschnitte 
der Provenance über die Methode getProvenanceByLocalRoot() abrufen. So 
traversiert der ProCP den gesamten Provenance-Baum und rekonstruiert die 
vollständige Provenance eines Datums (Abbildung 8.7). 


Die Provenance aller personenbezogenen Daten eines Betroffenen ergibt 
gemeinsam die Personal-Data-Provenance des Betroffenen. Diese wird zur 
grafischen Aufbereitung gesammelt an den ProDP PrivacyInsight gegeben. Die 
konkreten personenbezogenen Daten, auf die sich die Provenance bezieht, sind 
noch nicht Teil der Provenance. Diese Daten werden von PrivacyInsight bei 
Bedarf einzeln von den speichernden Systemen abgerufen. Hat der Betroffene 
kein Interesse an den konkreten Daten, erhält auch der ProCP/ProDP keine 
Kenntnis von ihnen (Anforderung 21). 


Die Personal-Data-Provenance wird nur so lange im ProCP/ProDP gespeichert, 
solange der Betroffene Zugriff auf die Auskunft nimmt (Anforderung 22). 
PrivacyInsight sieht dafür eine Logout-Möglichkeit und einen Timeout vor. 


Die verteilte Speicherung der Personal-Data-Provenance in den einzelnen 
ProSPs führt zu einer reduzierten Verfügbarkeit der Provenance. Insbesondere 
mobile Systeme und Arbeitsplatzsysteme sind nicht zwingend zum Abfrage- 
zeitpunkt erreichbar. Dies widerspricht dem Erfordernis einer jederzeit voll- 
ständigen Datenschutzauskunft (Anforderung 55). Personal-Data-Provenance 
sollte zu diesem Zweck immer ausreichend redundant gespeichert werden (An- 
forderung 56). Ein erster Lösungsansatz, angelehnt an verteilte Hashtabellen, 
findet sich bei Stritzke.! 


l Stritzke 2014. 
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8.3 Zwischenfazit 


Personal-Data-Provenance kann mit Hilfe der in Abschnitt 8.1 beschriebenen 
Informationsflusssemantik und Architektur systemübergreifend erhoben wer- 
den. Die Provenance wird in den ProSPs der einzelnen Domänen gespeichert 
und, entsprechend Konstruktionsziel A4, erst zum Abfragezeitpunkt entlang 
der Baumstruktur der Provenance eines personenbezogenen Datums aggregiert. 
Die vollständige Provenance wird dem Betroffenen auf der Auskunftsplattform 
PrivacyInsight zur Verfügung gestellt. 


Das hier vorgestellte Konzept hat im Vergleich zum Ansatz von Kelbert! den 
Vorteil, dass systemübergreifende Informationsflüsse von beliebigen Anwen- 
dungsschichten aus gestaltet werden können. Außerdem dient das Konzept 
dem Erhalt der informationellen Gewaltenteilung. Allerdings führt die höhere 
Komplexität des Informationsaustauschs bei der Übertragung von personenbe- 
zogenen Daten potentiell zu Performanceeinbußen. Insbesondere beim ersten 
Kontakt zweier Systeme kann der Austausch der Informationsflusssemantik zu 
Verzögerungen führen. 


! Kelbert/Pretschner 2015. 
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9 Eine Metrik für Unverkettbarkeit 


Das Datenschutz-Schutzziel der Unverkettbarkeit soll die Bildung von Per- 
sönlichkeitsprofilen verhindern. Unverkettbarkeit steht damit im Konflikt zur 
Transparenz.' Dieses Kapitel führt eine Metrik ein, die die Auswirkungen 
eines Datenschutzauskunftssystems auf die Unverkettbarkeit sichtbar macht.” 


Unverkettbarkeit wird sowohl in der juristischen als auch in der technischen 
Fachliteratur auf unterschiedlichste Art definiert, zum Teil nur grob umrissen. In 
Abschnitt 9.1.1 werden deshalb existierende Begriffsbestimmungen vorgestellt. 
Formale Modellierungsansätze werden in Abschnitt 9.1.2 diskutiert. Welche 
Aspekte für eine Unverkettbarkeitsdefiniton grundsätzlich erforderlich sind, 
wird in Abschnitt 9.2 ausgeführt, um in den Abschnitten 9.3 bis 9.7 zu 
einer allgemeinen Metrik für Unverkettbarkeit und ihrer Instanziierung in 
vier Varianten zu kommen. Im anschließenden Abschnitt 9.8 wird die für 
die Metrik erforderliche Modellierung des Angreiferwissens erläutert. Dabei 
sind insbesondere die Annahmen zum Hintergrundwissen des Angreifers von 
entscheidender Bedeutung. Eine Heuristik zur effizienten Berechnung der 
Metrik wird in Abschnitt 9.9 vorgestellt. Ihre praktische Anwendbarkeit wird 
demonstriert und in Abschnitt 9.10 diskutiert. 


' Vel. Kapitel 4.1.2 
? Wesentliche Teile dieses Kapitels wurden bereits in Bier 2016 veröffentlicht. 
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9 Eine Metrik fiir Unverkettbarkeit 


9.1 Existierende Begriffsbestimmungen und 
Modelle fiir Unverkettbarkeit 


Der Begriff der Unverkettbarkeit wurde in der Literatur bereits vielfach auf- 
gegriffen. Im Folgenden werden gängige Begriffsbestimmungen und Modelle 
vorgestellt. Ein besonderer Schwerpunkt wird auf die Bestimmung von Unver- 
kettbarkeit über eine Metrik gelegt. 


9.1.1 Existierende Begriffsbestimmungen für 
Unverkettbarkeit 


Unverkettbarkeit als Zielvorstellung des Datenschutzes wird indirekt anhand 
der möglichen Methoden zur Zielerreichung, Zweckbindung, Zwecktrennung 
sowie der informationellen und organisatorischen Gewaltenteilung umrissen. 


Bis dato wurde eine präzisere Definition in unterschiedlichster Art und Weise 
versucht. Als Systemeigenschaft formuliert, erfüllt ein System dann Unverkett- 
barkeit, wenn personenbezogene Daten nicht über Domänengrenzen hinweg, 
die durch Zweck und Kontext vorgegeben sind, „zusammengeführt“ werden 
können.! In der Definition nach ISO/IEC 15408-2:2008 ist Unverkettbarkeit 
die Eigenschaft, dass andere nicht in der Lange sind, festzustellen, ob zwei 
Operationen in einem System vom selben Benutzer verursacht wurden. Als 
konkreter, gewünschter Endzustand wird Unverkettbarkeit als die Unmöglich- 
keit des In-Bezug-Setzens personenbezogener Daten definiert.” Verkettung 
ist, darauf bezogen, das „Zusammenführen“ personenbezogener Daten mittels 
identifizierender Merkmale des Betroffenen.* 


Die genannten Definitionen sind zum einen einschränkend, weil sie bei- 
spielsweise die Methode des Zusammenführens oder die relevanten Entitäten 
vorgeben, zum anderen unklar in dem Sinne, dass beispielsweise nicht gesagt 


! Hansen/Jensen/Rost 2015. 
2 ULD/TU Dresden 2007, 19 £. 
3 ULD/TU Dresden 2007, 49. 
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wird, wer der Verketter ist und was „Zusammenführen“ eigentlich bedeutet. 
Festzustellen ist, dass es nicht eine Unverkettbarkeit, sondern eine Menge von 
Unverkettbarkeiten, abhängig von der betrachteten Verkettung, gibt. ! 


9.1.2 Bereits existierende absolute und relative 
Unverkettbarkeitsmodelle 


Unverkettbarkeit kann absolut oder relativ zu einem vorhergehenden Zustand 
definiert werden. Absolut gesehen sind zwei oder mehrere Entitäten? aus 
Sicht eines Angreifers dann unverkettbar, wenn der Angreifer nicht feststellen 
kann, ob die Entitäten innerhalb des definierten Modells in einem bestimmten 
Verhältnis zueinander stehen oder nicht. Daraus ergeben sich Modelle, die die 
Unverkettbarkeit von Entitäten danach bestimmen, ob ein Angreifer grundsätz- 
lich die Möglichkeit hat, etwas über eine vorher festgelegte Verkettungsrelation 
zwischen diesen Entitäten zu erfahren (,,all-or-nothing“-Prinzip). Die Modelle 
werden unter dem Begriff der Relationenunterscheidbarkeit zusammengefasst. 


Relative Unverkettbarkeit vergleicht die Unsicherheit eines Angreifers, welche 
Verkettungsrelation tatsächlich vorliegt, nach Interaktion mit einem System, mit 
der Unsicherheit, die bereits vor der Interaktion mit dem modellierten System 
bestand. Die darauf basierenden Metriken führen zu einem Wertekontinuum 
für den Grad der Unverkettbarkeit. 


Absolute Aussagen zur Unverkettbarkeit: Relationenunterscheidbarkeit 


Die Relationenunterscheidbarkeit ist ein formales Angreifermodell, mit Hilfe 
dessen evaluiert werden kann, ob ein Verfahren oder Protokoll die Unverkett- 
barkeit von Entitäten vollständig aufrechterhält oder nicht. 


1 So in der Tendenz bereits Pfitzmann/Hansen 2010, 12 sowie Bedner/Ackermann, DuD 2010, 
323 (324). 

2 Welche Entitäten betrachtet werden, variiert von Definition zu Definition. 

3 Pfitzmann/Hansen 2010, 12. 
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Das Modell von Bohli und Pashalidis definiert, inspiriert von einem Stan- 
dardexperiment fiir die Definition sicherer kryptographischer Schemata, der 
IND-CPA (Ciphertext indistinguishability - Chosen-plaintext Attack), einen 
Chosen-Relation-Angriff (CRA).! Hat ein Angreifer keinen, nicht vernach- 
lässigbaren, Vorteil (Unterscheidungsvorteil), hält das untersuchte Verfahren 
oder Protokoll die Unverkettbarkeit der Entitäten aufrecht. Die betrachteten 
Entitätsmengen sind Identifikatoren und Benutzer. 


Ein ähnliches Modell, in dem der Angreifer versucht zwischen zwei Kommu- 
nikationsmatrizen zu unterscheiden, findet sich bei Hevia und Micciancio.? Es 
ist spezifisch für Kommunikationssysteme mit der Relation „Sender-Nachricht- 
Empfänger“. 


Die Ideen von Hughes und Shmatikov orientieren sich wie die von Hevia und 
Bohli am „all-or-nothing“-Ansatz. 3 Abweichend werden nicht nur zweistellige, 
sondern auch dreistellige Relationen zwischen sogenannten Agenten und 
Markern einbezogen. 


In einer Situation, in der ein gewisser Wissenszuwachs unabdingbar ist und in 
Kauf genommen wird, wie bei Auskunftssystemen, ist ein „all-or-nothing“- 
Ansatz nicht hilfreich. Die Metrik würde jederzeit trivial messen, dass die 
Unverkettbarkeit nicht gewahrt bleibt. Deshalb untersucht diese Arbeit relative 
Ansätze im Sinne entropiebasierter Unverkettbarkeitsmetriken. 


Relative Aussagen zur Unverkettbarkeit: Entropiebasierte 
Unverkettbarkeitsmetriken 


In der Literatur hat sich die informationstheoretische Bestimmung relativer 
Unverkettbarkeit etabliert. Die gängigsten Unverkettbarkeitsmetriken, die einen 
kontinuierlichen Werteraum besitzen, basieren auf dem Verhältnis zwischen 
der Entropie des A-posteriori-Wissens des Angreifers und der maximalen 


! Bohli/Pashalidis 2011. 
2 Hevia/Micciancio 2008. 
3 Hughes/Shmatikov 2004. 
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Entropie. Die A-priori-Situation wird also als eine Situation ohne jedes Wissen 
festgelegt. 


Die Idee, Anonymität informationstheoretisch zu beschreiben, wurde bereits 
von Serjantov und Danezis ins Spiel gebracht.! Sie überführen das klassische 
„Anonymity Set“ auf ein nach den Wahrscheinlichkeiten der einzelnen Ele- 
mente der Menge gewichtetes Maß. Diaz et al. ergänzen die Normierung des 
Anonymitätsmaßes.? Die Arbeiten von Steinbrecher und Köpsell übertragen 
den informationstheoretischen Ansatz auf Unverkettbarkeit.” Der Ansatz wird 
von Franz et al.* aufgegriffen und von Pashalidis* von Aquivalenzrelationen 
auf homogene Relationen verallgemeinert. Franz et al. sowie Pashalidis lassen 
bewusst offen, welche Entitäten gemeint sind, während zuvor noch explizit von 
Benutzern, Nachrichten oder Aktivitäten gesprochen wird. 


Die Beschränkung auf Äquivalenzrelationen bzw. homogene Relationen und 
auf bestimmte Entitätsmengen sowie die Nichtberücksichtigung des tatsäch- 
lichen A-priori-Wissens des Angreifers sind die wesentlichen Nachteile der 
existierenden Ansätze.® 


In den folgenden Abschnitten wird eine Unverkettbarkeitsmetrik vorgestellt, 
die die genannten Beschränkungen überwindet und dennoch zugleich konkreter 
ist, als die rein begrifflichen Definitionen. Sie berücksichtigt A-priori-Wissen 
und ist offen für beliebige, auch mehrstellige, Relationen auf beliebigen Enti- 
tätsmengen. Als geeignete Metrik für ein Datenschutzauskunftssystem wird sie 
mit vier Relationen auf drei Entitätsmengen instanziiert und operationalisiert. 


' Serjantov/Danezis 2003. 

? Diaz et al. 2003. 

3 Steinbrecher/Köpsell 2003. 

4 Franz/Meyer/Pashalidis 2007. 

5 Pashalidis 2008. 

6 Die Privatsphäre wird nicht nur durch die Clusterung einzelner Merkmale gefährdet, sondern 
durch das Relationenprodukt unterschiedlicher Relationen auf unterschiedlichen Entitätsmengen. 
Eine Formalisierung des Relationenproduktes findet sich in Anhang F.1.1. 


229 


9 Eine Metrik fiir Unverkettbarkeit 


9.2 Aspekte einer Unverkettbarkeitsdefinition 


Aus einer Analyse der bereits existierenden Unverkettbarkeitsvorstellungen 
ergibt sich, dass die Festlegung der folgenden vier Aspekte erforderlich ist, um 
zu einer Unverkettbarkeitsdefinition zu kommen. Sie legen den Ausschnitt der 
Realität fest, in dem Unverkettbarkeit gemessen werden soll. Die vier Aspekte 
sind im Einzelnen: 


« die betrachteten Entitäten (£) 
e ihre Beziehungen zueinander (Verkettungsrelationen R) 


e der Verketter, in Analogie zur IT-Sicherheit auch als Angreifer / 
bezeichnet, aus dessen Perspektive die Unverkettbarkeit bestimmt wird 


e die Annahmen zum System ©” ,! in dem die Verkettung stattfinden kann 


Die vier Aspekte werden im Laufe dieses Kapitels mit Bezug auf ein Daten- 
schutzauskunftssystem mit Inhalt gefiillt. Sie wurden bereits von Pfitzmann 
und Hansen in ihrer Definition verwendet,2 jedoch nicht formal beschrieben. 
Diese Arbeit erweitert insbesondere die Möglichkeiten zur Formulierung von 
Verkettungsrelationen und die Berücksichtigung von Hintergrundwissen im 
Angreifermodell. 


Eine Verkettungsrelation R ist eine Teilmenge des kartesischen Produkts 
von n > 2 Teilmengen F1,..., En C E (RC E x--- x En). Um zu einer 
aussagekräftigen Definition zukommen, werden sowohl in der Literatur als auch 
in dieser Arbeit Teilmengen F,,..., En gleichartiger Entitäten (Entitätsmengen 
der Entitätsklassen) gewählt. Entitäten € € E sind gleichartig, wenn sie 
bestimmte Eigenschaften gemeinsam haben. 


1 © steht in diesem Kapitel nicht für einen Systemzustand, sondern für das System und sein 
Verhalten insgesamt. 

2 Deren Definition lautet im Original „Unlinkability of two or more items of interest (IOIs, e.g., 
subjects, messages, actions, ...) from an attacker’s perspective means that within the system 
(comprising these and possibly other items), the attacker cannot sufficiently distinguish whether 
these IOIs are related or not.“; Pfitzmann/Hansen 2010, 12, aktualisierte Fortschreibung von 
Pfitzmann/Köhntopp 2001. 
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Beispiel. Zwei Entitätsklassen wurden in dieser Arbeit bereits vorgestellt: 
Die Betroffenen und ihre personenbezogenen Daten mit den dazugehörigen 
Entitätsmengen Z und 9.' Der Personenbezug lässt sich durch die Verket- 
tungsrelation R$ C 9 x B beschreiben.” (d,b) € R“ gilt, falls das Datum 
d € 2 einen Personenbezug auf den Betroffenen b € B besitzt. 


Einstellige Relationen (Prädikate) führen zu keinem Verkettungsausdruck und 
können deshalb nicht Teil einer Unverkettbarkeitsdefinition sein. 


9.3 Eine allgemeine Metrik für Unverkettbarkeit 


Eine allgemeine Metrik für Unverkettbarkeit lässt sich bereits definieren, ohne 
sich auf die Entitäten, die Verkettungsrelation, den Angreifer und die Annahmen 
zum System festzulegen. Diese Festlegung wird erst für die Instanziierung der 
Metrik in den nachfolgenden Abschnitten vorgenommen. 


In den folgenden Abschnitten dieses Kapitels werden Wahrscheinlichkeiten 
gemäß des Bayesschen Wahrscheinlichkeitsbegriffes als „Grad (vernünftiger) 
Glaubwürdigkeit/persönlicher Überzeugung“ (degree of belief) verwendet. 


Wie bereits angedeutet, ist relative Unverkettbarkeit der Vergleich der Un- 
sicherheit des Angreifers <& bezüglich der wahren Verkettungsrelation Ry 
nach Interaktion mit dem Gesamtsystem ©” mit der Unsicherheit, die bereits 
vor der Interaktion mit dem modellierten System bestand.* Die Unsicherheit 
vor Interaktion ist vom Hintergrundwissen (A-priori-Wissen) des Angreifers 
abhängig. Die Interaktion mit ©” lässt den Angreifer Beobachtungen ma- 
chen (Beobachtungsereignis /). Das kombinierte Wissen des Angreifers aus 
Hintergrundwissen und Beobachtungen wird auch als A-posteriori-Wissen 
bezeichnet. 


1 Vel. Kapitel 6.1. 

2 Im Folgenden wird R< als die Identifikationsrelation bezeichnet. 

3 Die Verkettungsrelation R muss nirgendwo gespeichert sein. Sie ist gleichbedeutend mit den 
realen Beziehungen der Entitäten gemäß der Semantik der Verkettungsrelation. 
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Sei X eine Zufallsvariable tiber der endlichen Menge der Kandidatenrelatio- 
nen R. Kandidatenrelationen sind alle Relationen, die zur Beschreibung der 
Beziehungen zwischen den betrachteten Entitäten potentiell in Frage kommen. 
Sowohl vor als auch nach Interaktion mit dem Gesamtsystem ©” weist der 
Angreifer æ allen Kandidatenrelationen R € R einen Wahrscheinlichkeitswert 
P(X = R) zu.! P(X = R) ist die angenommene Wahrscheinlichkeit, dass R 
die tatsächliche Relation R- zwischen den Entitäten aus Pj,..., En ist. 


Beispiel. Angenommen es gibt nur die Betroffenen b,,b2 € B (Alice 
und Peter) sowie das Datum dı € 2 (Vorname), das zu einem der 
beiden Betroffenen gehört. Dann ist die Menge der Kandidatenrelatio- 
nen R = {{(b1,dı)},{(b2,dı)}} und die tatsächliche Relation lautet 
Rr = {(b1,dı)}. Ein Angreifer ohne weiteres Hintergrundwissen wür- 
de den beiden Kandidatenrelationen a priori die Wahrscheinlichkeitswerte 
P(X = {(b1,dı)}) = P(X = {(ba2,dı)}) = 0,5 zuweisen. 


Dann ergibt sich die Entropie des A-priori- bzw. A-posteriori-Wissens des 
Angreifers als: 


H(X)=-),P(X=R)lg,P(X=R) [H]=bit 
RER 
Wobei P(X = R)log, P(X = R) = 0 für P(X = R) = 0 angenommen 
wird. Die Entropie misst die Informationsmenge, die . noch braucht, um Rr 
vollständig zu identifizieren. 


Der Grad der Unverkettbarkeit (A(X,1)) ergibt sich als Verhältnis zwischen 
A-priori- und A-posteriori-Entropie (mit dem Beobachtungsereignis J): 


AX|D 


N zo 


Der Grad der Unverkettbarkeit beschreibt das Verhältnis zwischen der Situa- 
tion nach und der Situation vor der Interaktion des Angreifers </ mit dem 


! Ähnlich bereits bei Pashalidis 2008. 
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Gesamtsystem © bezüglich des noch benötigten Wissens zur vollständigen 
Aufdeckung der Relation. 


In bisherigen Arbeiten werden meist die A-priori-Situation und die maxima- 
le Unverkettbarkeit entsprechend der Maximum-Entropie-Methode gleich- 
gesetzt (Maximum-Entropie-Prior, H(X) = Hmax(X) = logz(|R|)). Bei 
allgemeinen Relationen bestimmt sich die Mächtigkeit der Menge der Kandi- 
datenrelationen aus der Größe der Potenzmenge des kartesischen Produkts: 
[R| = |P(Eı x x En)|. 


Ein Maximum-Entropie-Prior macht im diskutierten Szenario indes keinen 
Sinn. Eine Welt, in der es ein Datenschutzauskunftssystem gibt, kann nicht 
hinter das zurücktreten, was der zu beschreibende Angreifer schon im Vor- 
aus weiß. Es ist einzig und allein von Interesse, welchen negativen Einfluss 
der Einsatz des Datenschutzauskunftssystems auf die Unverkettbarkeit hat. 
Würde das Hintergrundwissen in der Berechnung der A-priori-Entropie nicht 
mitberücksichtigt, sondern ausschließlich in die A-posteriori-Entropie mitein- 
bezogen, würde die entstehende, initial maximale, Entropie die tatsächliche 
Wirkung der Einführung eines Datenschutzauskunftssystems verzerren. Die 
hinzukommende Verkettbarkeit würde systematisch überschätzt. Als Konse- 
quenz werden a priori die Beobachtungen aus Datenverarbeitungsvorgängen 
ohne den Einsatz eines Datenschutzauskunftssystems vorausgesetzt. A poste- 
riori werden die Beobachtungen aus denselben Datenverarbeitungsvorgängen 
unter Berücksichtigung des Einsatzes eines Datenschutzauskunftssystems ins 
Angreiferwissen mit aufgenommen. Es handelt sich also um ein Gedanken- 
experiment und keine tatsächliche Vorher-Nachher-Betrachtung. Statt eines 
Maximum-Entropie-Priors ist der Vergleichszustand (subjektiver Prior) schon 
ein Zustand mit partiellem Wissen. 


Abbildung 9.1 stellt die Situation anschaulich dar. Die Fläche A repräsentiert 
das gesamte Wissen, das zur vollständigen Aufdeckung der Unverkettbarkeits- 
relation erforderlich ist. Die Fläche B ist das A-priori-Wissen des Angreifers. 
Die Fläche C ist das durch die Interaktion mit £” gelernte Wissen. Die Flächen 
B und C bilden gemeinsam das A-posteriori-Wissen. Die Fläche D ist das auch 
a posteriori unbekannte Wissen. Der Grad der Unverkettbarkeit ergibt sich aus 
dem Verhältnis zwischen DundD+C. 
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Abbildung 9.1: Verhältnis der unterschiedlichen Wissensstände 


9.4 Anforderungen an 
Unverkettbarkeitsmetriken 


Da Anonymität als Spezialfall der Unverkettbarkeit aufgefasst wird,! wurden 
die Anforderungen an gute Anonymisierungsmetriken von Andersson und 
Lundin? wie folgt für Unverkettbarkeitsmetriken verallgemeinert: 


1. Eine Unverkettbarkeitsmetrik sollte ihre Analyse auf Wahrscheinlichkei- 
ten stützen. 


2. Eine Unverkettbarkeitsmetrik muss wohldefinierte und intuitive End- 
punkte für ihre Skala besitzen.’ 


3. Eine Unverkettbarkeitsmetrik muss so konstruiert sein, dass der Grad 
der Unverkettbarkeit um so höher ist, je näher die Verteilung der Kandi- 
datenrelationen an der Gleichverteilung ist. 


4. Die Elemente im Wertebereich der Metrik sollten wohldefiniert sein. 
5. Der Wertebereich der Metrik sollte geordnet und nicht zu grob sein. 


Die oben definierte Metrik erfüllt all diese Anforderungen mit Ausnahme 
der zweiten: Die Metrik hat zwar einen wohldefinierten unteren Endpunkt 


! Ausführungen dazu in Anhang F.1.2. 
2 C, Andersson/Lundin 2008. 
3 Beispielsweise 1 und n oder 0 und 1. 
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(0), kann aber nach oben beliebig groß werden. Denn sei H(X) #4 Hmax( X) 
(kein Maximum-Entropie-Prior), dann ist bei Beobachtungen, die der A- 
priori-Annahme entgegengesetzt sind, hypothetisch ein A(X,I) > 1 möglich. 
Korrigierte Fehleinschätzungen können für den Angreifer zu einer subjektiv hö- 
heren Entropie führen. Die Wahl eines realistischeren A-priori-Bezugspunktes 
wird also dadurch erkauft, dass die Skala von A(X,I) keinen wohldefinierten 
oberen Endpunkt besitzt. Allerdings ist als Maß der Unverkettbarkeit nicht 
der Grad der Unverkettbarkeit bezüglich eines bestimmten Angreifers von 
Interesse, sondern der niedrigste Grad der Unverkettbarkeit über alle Angreifer. 
Trivial lässt sich immer ein Angreifer konstruieren, der kein Hintergrundwissen 
hat (H(X) = Hmax(X)) und durch seine Beobachtungen nichts dazulernen 
kann (H(X | I) = H(X)). Dessen Grad der Unverkettbarkeit ist immer 
A(X,I) = 1. Somit ist der normierte globale Grad der Unverkettbarkeit 
Al] = ming ({A(X, Lev)}) € [03 1]! 


Zuletzt zwei wichtige Hinweise zum Verständnis der Metrik: Ein Grad der 
Unverkettbarkeit von 1 bedeutet nicht, dass Unverkettbarkeit bewahrt wird, 
sondern einzig und allein, dass sich am Status quo nichts ändert. Waren dem 
Angreifer schon zuvor fast alle Relationen bekannt, sind sie es ihm auch 
weiterhin. Umgekehrt spielt der Nenner (Prior) in der Formel zum Grad der 
Unverkettbarkeit keine Rolle, wenn der Zähler (Posterior) O ist. Ein Grad der 
Unverkettbarkeit von 0 bedeutet vollständiges Wissen des Angreifers ohne 
etwas tiber den Wissenszuwachs auszusagen. 


9.5 Provenance-Systemmodell 


Zwei mögliche Entitätsmengen für die Instanziierung der Metrik im Kon- 
text eines Datenschutzauskunftssystems wurden bereits in den Beispielen 
eingeführt: Die Betroffenen Z und die personenbezogenen Daten Y. Die 
dritte Entitätsmenge sind die Systeme Z. Ein System .Y hat nichts mit dem 


! Das Optimierungsproblem ist unter der Nebenbedingung zu lösen, dass ./ ein Angreifer aus der 
Menge aller Angreifer ist. 
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angegriffenen Gesamtsystem ©” zu tun. J ist eine Entität in den noch zu 
bestimmenden Verkettungsrelationen. © bezeichnet in der Instanziierung 
alle datenverarbeitenden Verfahren sowie das Datenschutzauskunftssystem. 


Konkret ist ein System eine Ansammlung technischer (z. B. ein Cluster) oder 
organisatorischer (z.B. eine Abteilung) Entitäten, denen ein gemeinsames 
Wissen unterstellt wird. Interne Datenflüsse und verarbeitete Daten sind allen 
beteiligten Entitäten bekannt. Sofern eine Ansammlung organisatorischer Enti- 
täten gemeint ist, korrespondiert der Systembegriff mit dem organisatorischen 
Stellenbegriff. Entspricht ein System einem konkreten IT-System, so hat dies 
technische, aber keine konzeptionellen Gründe. 


Im Szenario eines Datenschutzauskunftssystems versucht ein Angreifer un- 
ter anderem Informationen über die Beziehungen zwischen Systemen und 
personenbezogenen Daten zu bekommen. Diese Informationen sind Teil der 
Provenance. Die Differenzierung zwischen einzelnen Repräsentationen in 
einem System ist für die Formulierung der Verkettungsrelationen mit Bezug 
auf die in Abschnitt 9.6 berücksichtigten Angreifer nicht erforderlich. Aus 
diesem Grund wird das Provenance-Datenmodell aus Kapitel 6.3 auf ein 
Provenance-Systemmodell reduziert. 


Ein Provenance-System-Graph Y™ = (.%, Y™, col) ist ein kantengefärbter, 
gerichteter Graph mit den Knoten (Systemen) Z, den Kanten Z? C Z x Z 
und der Färbung col : Z? — P(9). Die Kanten verbinden Systeme abhängig 
von den Kanten zwischen den Repräsentationen im Provenance-Datenmodell. 
Die Kantenfärbung enthält die Information, welche Daten von einem System 
in ein anderes geflossen sind. Die genaue Ableitung des Provenance-System- 
Graphen aus dem Provenance-Graphen findet sich im Anhang F.3. 


Beispiel. Eine Betroffene wie Alice hat nach $ 34 BDSG Anspruch auf Aus- 
kunft über die zu ihrer Person gespeicherten personenbezogenen Daten, deren 
Herkunft, Empfänger und den Zweck der Speicherung. Empfänger können der 
Betroffene, Dritte, Auftragsdatenverarbeiter und Stellen innerhalb der verant- 
wortlichen Stelle sein. Der Stellenbegriff ist funktional und organisatorisch 
definiert (siehe Kapitel 3.7.2). 
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Die Kunden Alice Fox (bı) und Peter Trollig (bz) sind gleichzeitig auch Systeme 
nach obiger Definition. Die CloudyCloud GmbH ist als Auftragsdatenver- 
arbeiter für AdBokis tätig. Außerdem übermittelt AdBokis im Rahmen ihrer 
Geschäftsprozesse personenbezogene Daten an die PayPortal Inc. und die 
Bonus Card GmbH. Intern spielen bei der Datenverarbeitung die Abteilungen 
Kundenbetreuung, Vertrieb, IT und Infrastruktur und Recht eine Rolle. In der 
Abteilung Vertrieb wird neben dem System für den Onlineverkauf auch ein 
Archivserver betrieben. Zudem gibt es Arbeitsplatzsysteme, die im Vertrieb nor- 
malerweise nicht für die Verarbeitung personenbezogener Daten vorgesehen 
sind. Exemplarisch ist deshalb im Minimalbeispiel der Workspace23 enthalten. 
Alle diese Entitäten werden als Systeme s € Z bezeichnet. Tabelle 9.1 gibt 
einen vollständigen Überblick und weist der Übersicht halber jedem System 
eine Nummer zu. 


Tabelle 9.1: Systeme 


Bezeichnung 


Alice Fox 

Peter Trollig 
CloudyCloud GmbH 
PayPortal Inc. 

Bonus Card GmbH 
Kundenbetreuung 
Vertrieb — Onlineverkauf 
Vertrieb — Archiv 
Vertrieb — Workspace23 
IT und Infrastruktur 
Rechtsabteilung 


x 


=.. OMONDMNRWNe 


mo 


Der vollständige Provenance-System-Graph für die Betroffene Alice ist in 
Abbildung 9.2 zu sehen. Die Knoten sind die oben erwähnten Systeme. Die 
Kanten zeigen die Datenflüsse aller Daten aus Tabelle 6.1. Die jeweiligen IDs 
der Daten sind als Färbung auf den Kanten aufgetragen. 
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17, 18 


1, 2, 6, 13-15 © 
> 


1-3, 7-9, 20 


1-3,5 («) 


Abbildung 9.2: Tatsächliche Datenflüsse für Alice Fox (Daten als Kantenbeschriftung) 


9,6 Der Angreifer ./ 


Das Angreifermodell ist eine der Grundvoraussetzungen für die Bestimmung 
von Unverkettbarkeit. Es gibt die Leitlinien vor, an denen sich die Analyse 
der A-priori- und der A-posteriori-Situationen orientieren kann. Das Angrei- 
fermodell ist entsprechend der datenschutzrechtlichen Rahmenbedingungen 
auszugestalten. 


Der Angreifer kann Teil der datenverarbeitenden Organisation (verantwortliche 
Stelle) sein oder außerhalb der Organisation zu finden sein. Mögliche externe 
Angreifer sind: 


e unberechtigt Auskunftsersuchende 
e Cyberkriminelle 
e staatliche Stellen 


Ein unberechtigt Auskunftsersuchender stellt eine Auskunftsanfrage ohne 
nach den datenschutzrechtlichen Vorschriften auskunftsberechtigt zu sein. 
Der unberechtigt Auskunftsersuchende gibt sich als ein anderer Betroffener 
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aus oder meint fälschlicherweise selbst Betroffener zu sein. Sein Angriff 
besteht in der Verschleierung der eigenen Identität und Berechtigungen bei der 
Auskunftsanfrage. 


Annahme 1. Bei jedem Auskunftsersuchen wird die Authentizität des Ersu- 
chenden und dessen Autorisierung sicher überprüft. Auskünfte werden nur an 
authentische Betroffene und ausschließlich bezüglich deren personenbezogener 
Daten erteilt. 


Die Überprüfung der Authentizität eines Auskunftsersuchenden kann 
beispielsweise anhand eines gemeinsamen Geheimnisses erfolgen. Der 
unberechtigt Auskunftsersuchende kann unter obiger Annahme keine 
Beobachtungen machen. 


Ein Cyberkrimineller versucht illegitim an gespeicherte personenbezogene 
Daten zu gelangen, um diese für Erpressung, Betrug oder beliebige andere Ak- 
tivitäten zu verwenden. Der Cyberkriminelle versucht aktiv, unter Ausnutzung 
der Schwachstellen von IT-Systemen, an die Daten zu gelangen. 


Annahme 2. Nur autorisierte Systeme haben im Rahmen legitimer Prozesse 
Zugriff auf die Provenance. Sie wird über Kommunikationskanäle weiter- 
gegeben, deren Sicherheit äquivalent zur Sicherheit der zugrundeliegenden 
personenbezogenen Daten ist. 


Aufgrund dieser Annahme kann ein Cyberkrimineller aus dem Datenschutz- 
auskunftssystem nicht mehr Informationen ziehen, als wenn er die Organisation 
ohne existierendes Datenschutzauskunftssystem angreifen würde. 


Eine Sonderrolle spielen staatliche Stellen. Sofern ihr Zugriffswunsch auf 
personenbezogene Daten legitim und verhältnismäßig ist, kann sich eine 
Organisation dem Abgriff von Informationen nicht entgegenstellen. Ist der 
Zugriffswunsch illegitim, können sie analog zu Cyberkriminellen behandelt 
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werden. Staatliche Stellen werden deshalb im Folgenden nicht gesondert 
betrachtet. 


Neben den externen Angreifern gibt es auch eine Reihe möglicher interner 
Angreifer: 


e Vorgesetzte, die die Produktivität ihrer Mitarbeiter überwachen wollen 


e Organisationseinheiten (Systeme ç € S) mit (wirtschaftlichem) Inter- 
esse an den Daten der Betroffenen (Kunden) — genannt Systemangreifer 


(A5) 
e Betreiber der zentralen Infrastruktur für die Datenschutzauskunft (°) 


Der Vorgesetzte will das Datenschutzauskunftssystem einer Zweitverwendung 
zuführen, um seine eigenen Mitarbeiter zu kontrollieren. Da die Personal-Data- 
Provenance teilweise auch Zeitinformationen enthält, könnte sie hypothetisch 
zur Überwachung der Produktivität der Mitarbeiter verwendet werden. Der 
Mitarbeiterdatenschutz ist jedoch nicht im Fokus dieser Ausarbeitung und wird 
nachfolgend nicht berücksichtigt. 


Der Systemangreifer (£S) verarbeitet möglicherweise selbst personenbezogene 
Daten. Er möchte aber Wissen über weitere Verarbeitungsvorgänge gewinnen. 
Vorstellbar ist beispielsweise eine Marketingabteilung, die wissen möchte, in 
welchem Maße und unter Preisgabe welcher Informationen ein Kunde bisher 
den Kundenservice angefragt hat. 


Der zentrale Angreifer (</°) entsteht in seiner Sonderstellung erst durch das 
Datenschutzauskunftssystem. Er entspricht im Datenschutzauskunftssystem 
dem ProCP. Als Einstiegspunkt für den Abruf der gesamten Provenance-Kette 
erhält er die in Kapitel 8.2 beschriebenen Metadaten als zusätzliches Wissen 
aus dem Betrieb des Datenschutzauskunftssystems. 


Die zentrale IT und die verantwortliche Stelle an sich sind als Angreifer 
auszunehmen und als modelltechnisch vertrauenswürdig anzunehmen. Eine 
Vertrauenswürdigkeit dieser mächtigen Instanzen muss durch organisatorische 
Maßnahmen sichergestellt werden. Wären sie nicht vertrauenswürdig, könnten 
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sie im Zweifelsfall auf allen IT-Systemen eine Protokollinfrastruktur installie- 
ren, die dieselben Daten sammelt wie das Datenschutzauskunftssystem, nur 
ohne datenschutzrechtliche Vorgaben zu berücksichtigen. Kann der Organisa- 
tion nicht vertraut werden, ergibt auch ein Datenschutzauskunftssystem wenig 
Sinn, da dann der Auskunft an sich nicht vertraut werden kann. Im weiteren 
Verlauf werden deshalb zwei Angreifertypen betrachtet: Der Systemangreifer 
AS und der zentrale Angreifer °°. 


f° und æ ° werden als passive Angreifer angenommen. Sie halten die festgeleg- 
ten Kommunikationsprotokolle des Datenschutzauskunftssystems vollständig 
ein. Eine Missachtung der Kommunikationsprotokolle kann von den Kom- 
munikationspartnern festgestellt und organisatorisch verfolgt werden. Beide 
Angreifer haben nur auf die bei ihnen gespeicherten Daten Zugriff. Der Sys- 
temangreifer hat Zugriff auf die von ihm erhobene Provenance, der zentrale 
Angreifer hat Zugriff auf die unabhängig von Auskunftsanfragen zentral ge- 
speicherten Daten. Arbeiten mehrere Systeme ç € Z zusammen, werden sie 
gemeinsam als ein Systemangreifer .o/S mit gemeinsamem Hintergrundwissen 
und gemeinsamen Beobachtungen aufgefasst. Sie werden analog zu einem 
einzeln agierenden Systemangreifer behandelt. 


Das Wissen der beiden betrachteten Angreifer und weitere Modellannahmen 
werden im nächsten Abschnitt beschrieben. 


Annahmen zum Hintergrundwissen der Angreifer £S und &° sowie zu 
den Eigenschaften des modellierten Gesamtsystems ©” Die Verarbeitung 
personenbezogener Daten findet entlang etablierter Verarbeitungsprozesse statt. 
Diese sind von der verantwortlichen Stelle gemäß $ 4g Abs. 2 S. 1 BDSG 
1.V.m. $ 4e Satz 1 BDSG in einem internen Verfahrensverzeichnis zu doku- 
mentieren. Teil dieser Dokumentation sind die verarbeiteten Datenkategorien, 
eine Beschreibung der Verarbeitungsprozesse sowie die möglichen Empfänger 
der Daten. Aus letzterer Information ergibt sich die Möglichkeit der Verkettung 
einzelner Verarbeitungsprozesse. 


Es ist jedoch möglich, dass Daten auch außerhalb der vorgesehenen Pro- 
zesse verwendet werden. Dies ist entweder der Fall, wenn es sich um einen 
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Einzelfall handelt, oder wenn ein Verstoß gegen das datenschutzrechtliche 
Zweckbindungsgebot vorliegt. 


Wichtigster Baustein des A-priori-Hintergrundwissens der Angreifer ist das 
interne Verfahrensverzeichnis. Neben dem internen Verfahrensverzeichnis 
sind dem Angreifer auch allgemeine Unternehmensstatistiken bekannt. Solche 
Statistiken enthalten Informationen zur Anzahl der Kunden und zur Menge der 
verarbeiteten Daten. Daraus ergeben sich die folgenden drei Annahmen: 


Annahme 3. Dem Angreifer ist die Art und die Anzahl aller Systeme s E€ F a 
priori bekannt. 


Annahme 4. Dem Angreifer ist die Anzahl der von der Datenverarbeitung 
betroffenen Kunden |B| a priori bekannt. 


Annahme 5. Dem Angreifer ist die Anzahl der verarbeiteten personenbezoge- 
nen Daten | J| a priori bekannt. 


Uber das Verfahrensverzeichnis hinaus ist für die Angreifer c/° und ° die 
Anzahl der Systeme auch aus der Datenverarbeitung an sich zu schließen. 
Voraussetzung für die Datenverarbeitung der Angreifer ° ist, mit allen daten- 
verarbeitenden Systemen innerhalb der verantwortlichen Stelle kommunizieren 
zu können. Die zentrale Infrastruktur für die Datenschutzauskunft (.2/°) muss 
für ein Datenschutzauskunftssystem alle anderen Systeme erreichen können 
(Provenance-Collection) und muss von allen Systemen erreichbar sein. Die 
Anzahl der Systeme ließe sich also für beide Angreifertypen über eine Art 
„Netzwerkscan“ erschließen. 


Die Angaben zur Anzahl der verarbeiteten personenbezogenen Daten ist im 
Allgemeinen nur als grobe Schätzung verfügbar. Sind die Zahlen groß genug, 
hat der genaue Wert jedoch keinen merklichen Einfluss auf die Bestimmung 
der Unverkettbarkeitsmetriken. 


Ein Datum kann potentiell personenbezogenes Datum mehrerer Betroffener 
sein. Dies ist in der Provenance abbildbar und von den im nachfolgenden 
Abschnitt definierten Verkettungsrelationen erfassbar. Um die Erläuterungen 
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in Abschnitt 9.8 zu vereinfachen, wird dennoch o. B. d. A. angenommen, dass 
ein Datum nur einen Personenbezug zu einem Betroffenen haben kann. 


Annahme 6. Das Verhältnis von personenbezogenen Daten und Betroffenen 
ist eine n: 1-Beziehung. 


Die beiden letzten Annahmen 7 und 8, sind wichtige Annahmen zur Unabhän- 
gigkeit von Datenflüssen. Sie sind eine entscheidende Voraussetzung für die 
Berechenbarkeit der Unverkettbarkeitsmetriken. Beide Annahmen werden in 
der Realität nicht in jedem Fall vollständig eingehalten. Die durch sie induzierte 
Ungenauigkeit kann jedoch nur zu einem Unterschätzen des A-priori-Wissens 
des Angreifers führen. Das Delta zur A-posteriori-Situation wird dann größer. 
Die Gefährdung für den Datenschutz wird überschätzt. Deshalb sind die An- 
nahmen vom Ergebnis her gedacht sinnvoller, als unbelegte Annahmen über 
die Abhängigkeit von Datenflüssen zu treffen, welche zu einem Unterschätzen 
des Datenschutzrisikos führen könnten. 


Annahme 7. Das A-priori-Wissen zu Datenflüssen (Verarbeitungsprozessen) 
ist nur von der Kategorie der Daten, nicht von den Daten selbst abhängig. 


Es ist für den Datenfluss beispielsweise egal aus welchen Ziffern die IBAN 
des Betroffenen besteht oder welchen Vornamen er hat. Eine Abhängigkeit 
kann in der Realität (s.o.) immer dann vorkommen, wenn ein Prozess mehrere 
Verarbeitungsalternativen vorgibt, deren Wahl abhängig vom Inhalt der Daten 
(z.B. Bonität, Alter, Lieferart) ist. Auf Datenkategorieebene kann man dies 
nur über die allgemeine Wahrscheinlichkeit der Alternativen fassen. Dies kann 
problematisch sein, falls angenommen wird, dass der Angreifer den Inhalt der 
Daten kennenlernen kann. 


Annahme 8. Die Flüsse zweier Daten sind stochastisch unabhängig vonein- 
ander. 


Die Wahrscheinlichkeit für ein Datum d für einen bestimmten Fluss ist gleich 
hoch, unabhängig davon, ob ein Datum d’ entsprechend der Verfahren oder 
abweichend geflossen ist. 
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Was jedoch nicht abgedeckt wird, ist die Aneinanderreihung von Verfahren 
und die Beriicksichtigung von Verarbeitungsalternativen. In diesen beiden 
Fallen ist es durchaus so, dass Daten einen gemeinsamen Weg nehmen. FlieBen 
Daten immer gemeinsam, sollten die Daten verbunden als ein Datum behandelt 
werden. Solch ein zusammengefasstes Datum ist dann wieder unabhängig von 
den Datenflüssen anderer Daten. 


Darüber hinaus sind auch Situationen denkbar, in denen Daten zwar nicht 
immer gemeinsam verarbeitet werden, jedoch von der Verarbeitung des einen 
Datums auf eine höhere Wahrscheinlichkeit der Verarbeitung eines anderen 
Datums geschlossen werden kann. Deshalb bleibt die Unabhängigkeitsannah- 
me letztendlich eine Vereinfachung, die dem Vorgehen vorzuziehen ist, mit 
Abhängigkeiten zu arbeiten, die nicht bekannt sind. 


9.7 Instanziierung der Unverkettbarkeit als 
Gegenspielerin der Transparenz 


Die relevanten Entitäten ergeben sich aus den Teilinformationen der Daten- 
schutzauskunft. Es sind die Systeme ç € 7, die personenbezogenen Daten 
d € 2 und die Betroffenen b € 2. Gleiches gilt für die Verkettungsrelationen, 
die über diesen Entitäten definiert sind. Sie ergeben sich außerdem aus den 
technischen Anforderungen in Kapitel 4.4. Sie bilden das Interesse des Angrei- 
fers an den zu einem Betroffenen gespeicherten personenbezogenen Daten (R<, 
Anforderung 45), an der Herkunft und den Empfängern personenbezogener 
Daten (RP, Anforderung 43) und am zweckbestimmten Verarbeitungsort per- 
sonenbezogener Daten (RY , Anforderung 42) ab. R= ergibt sich aus dem Gebot 
der Zwecktrennung (Anforderung 44). Wird die Zwecktrennung überwunden, 
kann ein Persönlichkeitsprofil des Betroffenen hergestellt werden, unabhängig 
davon, ob schon klar ist, wer er ist. Alle Relationen stellen immer nur die 
Situation zu einem bestimmten Zeitpunkt dar. Werden Daten neu erhoben oder 
weitergegeben, ändern sich die Relationen. Die vier genannten Relationen sind 
wie folgt definiert: 
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Die Identifikationsrelation R< C 9 x 2 gibt an, ob das Datum de 2 
einen Personenbezug auf den Betroffenen b € Z besitzt. 


Die Verkniipfungsrelation R= C 2 x 29 gibt an, ob zwei Daten 
d, d! € 9 einen Personenbezug auf denselben (aber unbekannten) 
Betroffenen besitzen. 


Die Speicher- und Verarbeitungsrelation RY C SY x 9 gibt für alle 
Systeme ç € Z an, ob sie das Datum d € D verarbeitet und/oder 
gespeichert haben. 


Die Datenflussrelation RP C Z x Z x 9 gibt für zwei Systeme 
S, S € F an, ob sie für ein bestimmtes personenbezogenes Datum 
d € 2 in einer direkten Vorgänger-Nachfolger-Beziehung stehen. 


Damit ist die Definition der Unverkettbarkeit für ein Datenschutzauskunftssys- 
tem vollständig. 


Definition 9.1. Der Grad der Unverkettbarkeit ist die Unsicherheit eines An- 
greifers £S oder A über die wahre Verkettungsrelation in RS, R=, RY oder 
RP im Gesamtsystem ©” , nachdem das Beobachtungsereignis I eingetreten 
ist, im Vergleich zur Unsicherheit mit seinem vorherigen Wissensstand. 


Bei manchen Unverkettbarkeitsmetriken ist es möglich, die Verkettungsrela- 
tion auf unterschiedlichen Entitätsteilmengen zu bestimmen. A(X <, J) und 
A(X=, I) sind globale Metriken. Bei der Bestimmung des Grads der Un- 
verkettbarkeit sind alle Betroffenen Z und alle personenbezogenen Daten 2 
miteinzubeziehen. 


Anders stellt sich die Situation bei RP und RY dar. Der Grad der Unverkettbar- 
keit bezüglich dieser Mengen ist global und lokal bestimmbar. Lokal meint die 
Fokussierung auf bestimmte Systeme ç € Z oder Betroffene b € 2. Im Kon- 
text der Datenschutzauskunft ist für einen Betroffenen nur relevant, wie sich die 
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Unverkettbarkeit der Fliisse seiner personenbezogenen Daten entwickelt, um zu 
entscheiden, ob er für oder gegen technische Transparenzmaßnahmen plädiert. 
Deshalb werden im Abschnitt 9.8.2 nur die Daten in der Teilmenge 9, C 9, im 
Beispiel die personenbezogenen Daten von Alice Darice C 2, betrachtet. Im 
Text wird dennoch im Sinne einer allgemeingültigen Darstellung von 2 gespro- 
chen. Gleichzeitig wird im Abschnitt 9.8.2 angenommen, dass dem Angreifer a 
priori bekannt ist, welche Identifikatoren von personenbezogenen Daten (aber 
nicht welcher Kategorie) zu welchem Betroffenen gehören. Die Unsicherheit 
über dieses Faktum wird bereits durch den Grad der Unverkettbarkeit von R< 
gemessen. 


Beispiel. Für die Bestimmung des Grads der Unverkettbarkeit wird das 
A-priori-Wissen der Angreifer in Bezug zum sich aus den tatsächlichen Daten- 
flüssen ergebenden A-posteriori-Wissen gesetzt. In den Beispielen des Folge- 
abschnitts werden die tatsächlichen Datenflüsse von Alice verwendet. Alice 
werden in der Auskunft die in Abbildung 9.2 bereits dargestellten tatsächlichen 
Datenflüsse mitgeteilt. 


9.8 Bestimmung des Grads der 
Unverkettbarkeit unter Berücksichtigung 
des A-priori- und A-posteriori-Wissens der 
Angreifer 


Um den Grad der Unverkettbarkeit bezüglich der vier genannten Relatio- 
nen zu bestimmen, ist es erforderlich, das Hintergrundwissen der Angreifer 
und den Wissenszuwachs durch die Einführung der Datenschutzauskunft 
messbar zu machen. Das Hintergrundwissen der Angreifer geht in die A- 
priori-Wahrscheinlichkeiten P(X = R) mit ein. Der Wissenszuwachs der 
Angreifer wird durch das Beobachtungsereignis J und die daraus resultieren- 
den A-posteriori-Wahrscheinlichkeiten P(X = R | T) erklärt. A-priori- und 
A-posteriori-Wahrscheinlichkeitsverteilungen aller vier Relationen werden in 
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diesem Abschnitt erläutert und anhand des Minimalbeispiels aus Kapitel 1.6 
bestimmt. 


9.8.1 Bestimmung der Wahrscheinlichkeitsverteilungen 
von X“ und X= 


Für die beiden Relationen R< und R= gilt, dass es, mit Ausnahme der 
Mächtigkeit der Mengen Z und 9, kein globales Hintergrundwissen gibt. 


Ein Systemangreifer .o/° kann möglicherweise über den Inhalt der personen- 
bezogenen Daten, die er selbst verarbeitet, auf deren Personenbezug schließen 
(Einfluss auf die Wahrscheinlichkeitsverteilung von X< und X=). Zudem 
kann die gemeinsame Verarbeitung von Daten unterschiedlicher Datenkatego- 
rien für solch einen Angreifer ein Indiz sein, dass zwei Daten zum gleichen 
Betroffenen gehören (Einfluss auf die Wahrscheinlichkeitsverteilung von X5). 
Beides ist sehr spezifisch für den jeweiligen Angreifer. Letztendlich ist die 
Bestimmbarkeit des Unverkettbarkeitspriors jedoch nur dann relevant, wenn er 
sich potentiell vom Posterior unterscheiden kann. Dies ist für Systemangreifer 
nicht der Fall. Durch das vorgestellte Datenschutzauskunftssystem werden auf 
den Systemen nur solche Teile der Provenance vorgehalten, die auf Ereignisse 
im jeweilige System zurückzuführen sind. Daraus folgt für solche Angreifer 
A(X<, I) = A(X=, I) =1. 


Der zentrale Angreifer 7° verarbeitet selbst keine personenbezogenen Da- 
ten. Für ihn sind H(X<) = Hymax(X<) = log, |R“| und H(X=) = 
Hmax( XF) = logy |R=|. Die A-Priori-Entropie des Angreifers hängt da- 
mit einzig von der Mächtigkeit der Menge der beiden Kandidatenrelationen 
ab. 


Die Mächtigkeit der Menge der Kandidatenrelationen ist unter Berücksichtigung 
von Annahme 6 für die Identifikationsrelation durch |R “| = |A|!7! gegeben. 


Beispiel. Die Anzahl der Kandidatenrelationen für |2| = 30 und |B| = 2 ist 
230 = 1073 741 824. 
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R= ist die über den Mittler! Z aus R< abgeleitete Aquivalenzrelation.” Bei 
Äquivalenzrelation ist die Anzahl möglicher Relationen durch die Bellsche 
Zahl Bg, ,° die Anzahl der Partitionen (Zerlegungen in disjunkte nichtleere 
Teilmengen) der zugrundeliegenden Menge 9, gegeben. Die Bellsche Zahl 
lässt sich über die Stirling-Zahl zweiter Art bestimmen: 


Bn = 5 Sn,k 
k=0 


mit Sn,k = Sn-1,k-1 +k. Sn-1,k 
sowie Syn = lund Sr =0fük=0<nVn<k. 


Da R= auf R< zurückzuführen ist, sind die tatsächlichen Kandidatenrelationen 
durch die Anzahl der Betroffenen |Z| beschränkt. Nur k-Partitionen mit k < 
|Z| sind möglich. Obige Formel ist deshalb in korrigierter Form anzuwenden: 


min(|4],|F]) 


IR=| = 5 S|9\,k 


k=0 


Beispiel. Die Anzahl der Kandidatenrelationen für |2| = 30 und |B| = 2 ist 
|R=| = nv, S30,k = 536 870 912. In diesem Spezialfall mit zwei Betroffe- 
nen ist |R=| = $-|R<|, da Sng = "1-1. 


A posteriori, also unter Einsatz des Datenschutzauskunftssystems, erhält 
der zentrale Angreifer weitere Informationen J. Bei jeder Erhebung eines 
personenbezogenen Datums wird ihm ein pseudonymer Identifikator für das 
erhobene Datum zusammen mit Informationen zum Betroffenen übermittelt. 


1 Auf die Elemente eines Mittlers werden in der ursprünglichen Relation die Aquivalenzklassen 
der zweiten Entitätsmenge abgebildet. Genaueres findet sich in Anhang F.1.1. 

? Herleitung und Beweis finden sich in Anhang F.1.3. Aufgrund von Annahme 6 ist R“ rechts- 
eindeutig. Da Betroffene, für die keine personenbezogene Daten verarbeitet werden, auf nil 
abgebildet werden können, ist R“ auch linkstotal. 

3 Bell 1934. 
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Daraus kann der Angreifer nicht schließen, welches personenbezogene Datum 
oder welche Kategorie personenbezogener Daten erhoben wurde. Allerdings 
kann er bestimmen, wie viele personenbezogenen Daten für jeden einzelnen 
Betroffenen erhoben wurden. Kandidatenrelationen, die keine entsprechende 
Struktur aufweisen, kann er ausschließen. 


Seien die dem Angreifer bekannt gewordenen k-Partitionen für die Menge der 
Daten 2 von der Größe j1, j2, . . - , Jr. Dann sind 


(R= € R= | P(X= = R5 | N # 0)| 


= i) G ao u m — (jı + j2 a 
Ji J2 jk 
und 


|(R< € R< | P(X* = R* | I) # 0)| 
= k! - (RE € R= | P(X= = FE | I) #0). 


Unter Weiterbestehen der Gleichverteilungsannahme ergibt sich die A- 
posteriori-Entropie direkt aus der Mächtigkeit der obigen beiden Mengen. 


Beispiel. Fiir Alice wurden 20 personenbezogene Daten erhoben, fiir Peter 
10. Damit sinkt die Anzahl der möglichen Relationen R= auf |( R= € R= | 
P(X= = R= | I) # 0)| = (56) = (35) = 30045015. Folglich ist der resul- 
tierende Grad der Unverkettbarkeit A(X”,I) = ee N aes N 
0,8566. 

Die Anzahl der verbleibenden Identifikationsrelation ist (RS € RS | 
P(X< = R“ | I) # 0)| = 2! - 30045015 = 60090030. Entsprechend 
ist der resultierende Grad der Unverkettbarkeit A(X <, 1) = run 030. es 


log, 230 
25,8406 _, 
50 = 0,8614. 


2 
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9.8.2 Bestimmung der Wahrscheinlichkeitsverteilungen 
von X? und X” 


Unter der Annahme, dass die Weitergaben unterschiedlicher personenbezogener 
Daten voneinander unabhängig sind (Annahme 8), kann die Wahrscheinlichkeit 
P(X = RP) für eine Kandidatenrelation RP € RP aus den Wahrschein- 
lichkeiten für die Teilrelationen je Datum P(X = RF) mit RÈ C Sx S 
berechnet werden. Es gilt PX? = R®) = [Juco P(XẸ = RZ). 


Das Wissen des Angreifers setzt sich aus drei Teilen zusammen: Dem Wis- 
sen über die Kategorie eines personenbezogenen Datums, dem Wissen über 
die Herkunft eines personenbezogenen Datums und dem Wissen über die 
Verarbeitungsverfahren. 


Datenkategorie Das Wissen eines Angreifers wird zunächst dadurch charak- 
terisiert, inwiefern ihm die Kategorie des personenbezogenen Datums bekannt 
ist. Die Kategorie des Datums bestimmt dessen Herkunft und Verarbeitung 
gemäß Verfahrensverzeichnis. Jedem Datum ist seine Datenkategorie über 
die Funktion v : 2 — © zugewiesen. Die Wahrscheinlichkeitsverteilung 
P(X» = 0) gibt die Wahrscheinlichkeit der Datenkategorien 6 € © für ein 
gegebenes Datum an. Ist dem Angreifer das Datum inhaltlich bekannt, ist ihm 
zwangsläufig auch dessen Kategorie bekannt. 


P(X? = RZ) = 5 P(X? = RZ | Xo = 0)P(Xo = 0) 
960 


Beispiel. Die Zuordnung zwischen Daten und Datenkategorien ist einem 
Systemangreifer fiir diejenigen Daten bekannt, die er selbst verarbeitet. So 
ist &, bekannt, dass (dıs) = 014 (Profilbild) ist. Für alle anderen Da- 
ten sowie grundsätzlich für den zentralen Angreifer muss entsprechend der 
Maximum-Entropie-Methode die Gleichverteilung P(Xg = 0;) = el fiir 
i € {1,...,]O]} angenommen werden. 


250 


9.8 Bestimmung des Grads der Unverkettbarkeit 


Herkunft Das Wissen eines Angreifers wird außerdem dadurch charakteri- 
siert, inwiefern ihm die Herkunft der personenbezogenen Daten bekannt ist. 
Die Herkunft der personenbezogenen Daten ist von der Kategorie der Daten 
abhängig. Die Wahrscheinlichkeiten der Zufallsvariable X, für bestimmte Start- 
systeme ç € .Y, abhängig von der Datenkategorie, sind P(X. = s | X = 0). 
Häufig ist die Herkunft von personenbezogenen Daten einer Kategorie eindeu- 
tig, in den meisten Fällen ist es der Betroffene selbst.! Ist das Herkunftssystem 
sı € Z, dann ist die Wahrscheinlichkeit für die Herkunft des Datums aus dem 
jeweiligen System P(X, = sı | Xo = 0) = 1 sowie P(X; = si | Xo = 0) = 0 
fiir i € {2,...,|.7%|}. Kommen mehrere Systeme in Frage, dann ist die Ge- 
samtwahrscheinlichkeit 


P(X? = RF | Xp = 8) 


= Br = RF | X; =S, Xo = P(X, = s | Xo = 8). 
SES 


Beispiel. Alle personenbezogenen Daten, bis auf jene der Kategorien Rech- 
nung und Empfehlung, werden ausschließlich beim Betroffenen selbst erhoben. 
Für diese ist das Herkunftssystem sı bekannt. 

Eine Rechnung wird immer durch den Rechnungsgenerator im Onlineshop- 
system des Vertriebs erzeugt. Dies ist den Angreifern ebenfalls aus dem 
Verfahrensverzeichnis bekannt. Das Herkunftssystem für die Rechnung ist 
damit aus Sicht der Angreifer eindeutig s7. 

Über die Quelle einer Empfehlung (016) ist hingegen nur bekannt, dass 
sie von einem Kunden kommen muss. Da über das Verhältnis der Kunden 
untereinander nichts im Verfahrensverzeichnis enthalten ist, ist die A-priori- 
Wahrscheinlichkeit der Angreifer für das Herkunftssystem über alle vorhanden 
Kunden gleichverteilt. Im Beispiel wird der Einfachheit halber nur von zwei 


1 0.B.d.A. ist das System, das den Betroffenen repräsentiert, das System sı € J. 
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Kunden ausgegangen. Dann ergeben sich die Wahrscheinlichkeiten 


0,5 füri=1Vi=2 


0 sonst. 


P(X, = si | Xo = 016) “| 


Einschub Jede zweistellige! Relation R über endlichen Mengen kann als 
binäre bzw. boolsche Matrix R= = (rij), ri; € {0,1} dargestellt werden. Die 
Einträge der Matrix r;; stehen für die Realisationen der wie folgt definierten 
Zufallsvariablen X;;: 


Xij :R- {0,1} 


1 li iLE) ER 
Ro fiir (€i,€;) 
0 sonst. 


Der Eintrag bzw. das Ereignis 1 bedeutet, dass die durch den Index gegebenen 
Elemente in Relation zueinander stehen, der Eintrag 0, dass keine Beziehung 
vorliegt. Im Folgenden wird deshalb zur Vereinfachung nicht zwischen der 
Relation R und ihrer Matrixdarstellung R differenziert. 


Tij 1s X;; 1< (eie) E R 
Daraus abgeleitet wird folgende Kurzschreibweise verwendet: 


Rri sin Pina origin > R= {len Eii (Enn Ejs): sewi CR 


Beispiel. Ein Datum d € È wird nur durch den Betroffenen selbst gespeichert. 


! Gilt grundsätzlich auch für mehrstellige Relationen. 
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Verarbeitungsverfahren Bezüglich der konkreten Datenflüsse stützen sich 
die Angreifer auf die Angaben des Verfahrensverzeichnisses. Dieses hinterlegt 
für alle Daten die vorgesehenen Verarbeitungsprozesse. Das Wissen der An- 
greifer wird als Matrix der bedingten Flusswahrscheinlichkeiten W modelliert. 
Der Eintrag w;; gibt die Wahrscheinlichkeit an, mit der ein Fluss von s; nach 
Sj, angenommen wird, unter der Bedingung, dass das Datum bereits in si 
verarbeitet wurde: 


Wo: {1,...,m} x {1,...,m} — [0,1] 
(ij) => wij = P(XG,; =1| 
Xp; 1, X; = S, Xo = 0) 


mit m = |Z|. Implizit ist w;; = 1. Der reflexive Fluss, gleichbedeutend mit 
der Speicherung und Verarbeitung im System (Vd,i : P(r5;;) = P(r¥,)), ist 
vollständig durch die eingehenden Flüsse erklärt: 


X>, =1, X% =s, Xo =0)=1 


P(XẸ;, =1|vj € {1,--,i—1,i +1, m}: 


XÈ, =0,X; =s, X9 =0)=0 
1:1 
Die inverse Matrix Wọ = 1 — Wọ mit L =| : `, : 
bei 
enthält die jeweiligen Gegenwahrscheinlichkeiten W;; = P(X%,, = 0 | Xfi, = 


1, X; = S, Xo = 0). Außerdem gilt für alle Datenflussrelationen P(X È ;=0] 
X? = 0, X; = s, Xo = 0) = 1 und P(X F =1 | XẸ; = 0, X; = s, Xo 

0) = 0. Es kann keine ausgehenden Flüsse geben, falls es keinen eingehenden 
Fluss gibt. Damit ist der Wahrscheinlichkeitsbaum für die Datenflussrelation 


vollständig erklärt. 


Die in den bedingten Flusswahrscheinlichkeiten zum Ausdruck kommenden 
Pfade ergeben sich aus dem Verfahrensverzeichnis. Bezüglich der Abläufe der 
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Verfahren wird davon ausgegangen, dass ein Angreifer auf grobes Erfahrungs- 
wissen zurückgreifen kann, das sich in zwei zentralen Parametern ausdrücken 
lässt. 


Zunächst hängt die Wahrscheinlichkeit von Flüssen in linearen Verfahren 
maßgeblich von der Fortschrittsquote w € (0,5; 1] eines Prozesses ab (Wie 
viele Daten erreichen anteilig den nächsten Prozessschritt?). Dieser Parameter 
wird überall dort in der Flussmatrix eingesetzt, wo ein Fluss einem Prozess- 
schritt entspricht. Die Fortschrittsquote sollte immer größer als 0,5 sein, da 
ein Prozessschritt, der nicht im Regelfall stattfindet, kein etabliertes Verfahren 
sein kann. Verzweigungen in einem Verfahren sind als Sonderfall davon ausge- 
nommen. In sich verzweigenden Prozessen ist punktuell der Anteil der Daten 
zu berücksichtigen, die auf die eine oder die andere Weise weiterverarbeitet 
werden. 


Unvorhergesehene Abweichungen vom Verfahren werden durch eine Fehler- 
wahrscheinlichkeit o € |0;0,5) beschrieben. Mit dieser Fehlerwahrschein- 
lichkeit finden Flüsse zu und zwischen Systemen außerhalb des vorgesehenen 
Prozessablaufs statt. Je nach Detailgrad der Modellierung des Hintergrund- 
wissens können Fortschrittsquote und Fehlerwahrscheinlichkeit pro Verfahren, 
pro Datentyp oder global angegeben werden. Bei detaillierteren plausiblen 
Annahmen über das Hintergrundwissen eines Angreifers können die Wahr- 
scheinlichkeiten für bestimmte Flüsse individuell festgelegt werden. 


Beispiel. Die AdBokis Buchclub Cube hat eae Verfahren etabliert: 
Registrierung, Bestellung, Zahlungsabwick ', Kundendatenarchivierung, 
Missbrauchsbekämpfung Ba ERBEN O 9.3). 


Die Fortschrittsquote wird mit 90 % (w = 0,9) und die Fehlerwahrscheinlich- 
keit mit o = 0,02 angenommen. Betrachten wir exemplarisch das Profilfoto 
014. Es ist Teil von zwei Verarbeitungsprozessen, der Registrierung und der 
Kundendatenarchivierung. Im Regelfall werden alle Profilfotos, die bei der 
Registrierung (S7) übermittelt werden, auch in der Cloud (S3) gespeichert. 
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Herkunftssystem ist immer der Kunde (Betroffene) sı. Dann ergibt sich folgende 
Flussmatrix: 


[ 1 0,02 0,02 0,02 0,02 0,02 0,9 0,02 0,02 0,02 0,02 ] 
8.02 -L Olli re nen 0,02 
0,02 0,02 1. : 
0,02: 
0,02 
Weis: =| 0,02 : 
0,02 : 0,9 
0,02 : 
0,02 : bee a ee. 4 
0,02 - a, 71 0,02 
0,02 0,02 Meanie a tuadanary tea aaah na aie ett salen, heats 0,02 1 


3, 7, 8, 17 


S © © © 


Abbildung 9.3: Verfahren (Datenkategorien als Kantenbeschriftung) 


255 


9 Eine Metrik fiir Unverkettbarkeit 


Anmerkung Aus der Definition bedingter Wahrscheinlichkeiten erhält man 
durch vollständige Induktion die Kettenregel ! 


P(X? = Ry | X: =s, Xo = 0) = 


> pd 
P (xg, = aij | 
> _„D > _ b> 
Xai Ta: Alina Tail 
> _ > > pd 
II II Xliii = Tait n Aami ~ as 
1ES JEF . F 
X sys = s, Xo = 0), i=j 


P(X, = A ==), ii 


Auf dieser Grundlage kann die A-priori-Wahrscheinlichkeit für die einzelnen 
Kandidatenrelationen iterativ berechnet werden (mit W als der zur Relation 
gehörigen Flussmatrix): 


P(X? = en | X; = <1, Xo = 0) 


= W11W12 Wmm = W11W12°** Wim = P 


P(X? = RÈ 


> _1,D ye 
draumbrasmmrge 


=1 | X, =o, Xo = 6) 


p = = 
= ——W12W21W22W23 °° * W2m 
W12 


Berechenbarkeit Die Komplexität der vollständigen Berechnung der Wahr- 
scheinlichkeiten aller möglichen Kandidatenrelationen ist allerdings in 
oR I I). Selbst bei wenigen Systemen ist somit die Berechenbarkeit 


l Russell/Norvig 2010, 514. 
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der Wahrscheinlichkeitsverteilung nicht mehr gegeben. Deshalb ist nur ei- 
ne heuristische Lösung entsprechend dem in Abschnitt 9.9 beschriebenen 
Verfahren möglich. 


Beispiel. Für obige Flussmatrix ergibt sich die Wahrscheinlichkeit, dass 
das Datum nur im Herkunftssystem Sı verarbeitet wird, sofern es von der 
Datenkategorie 0,4 ist, als 


P(X? = R? | X; = s1, Xo = O14) = 1 - 0,1 - 0,98? = 0,0834 


E o 
dyrgy,=1 


Würde man kombinatorisch aus den Wahrscheinlichkeiten P(X = RẸ) die 
Gesamtwahrscheinlichkeit P(X” = RP) = J [uc P(XẸ = RZ) berechnen, 
hätte dies eine Komplexität in O(|9]|71:11) 
hängige Teilsysteme (Teilrelationen), dass die Entropie eine additive Größe ist 
(A(X?) = A(X) re +H(X7,) mit n = |2|)! 


. Erfreulicherweise gilt für unab- 


Somit lässt sich die Gesamtwahrscheinlichkeit aus den approximierten Teil- 
wahrscheinlichkeiten bestimmen. 


Die Wahrscheinlichkeitsverteilung für XY lässt sich auf Grundlage der Wahr- 
scheinlichkeitsverteilung von X” ermitteln: 


P(X” = R’) = 5 P(X? = R°) 
R> ER> | R> =y RY 
mit R? = RY 
Vde 9,se FL: ((ds,s) E RPA 
(d,s) € RY) V ((d.s,s) ER” A (d,s) € R”) 


Zu diesem allgemeinen Hintergrundwissen kommen noch die jeweiligen Beob- 
achtungen der Angreifer hinzu. Ein Systemangreifer æ$ kann die Datenflüsse 


! Der Beweis findet sich in Anhang F.2. 
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durch sein System überwachen. Die Likelihood P(/ | RP) ist für solche 
Beobachtungen sicher 1 oder 0. Die A-posteriori-Wahrscheinlichkeit beträgt 


P(I | RP)P(RP) PU | RF)P(RP) 


P(R® |I) = PCO) = Ben P(I | RP/)P(RP’) 


D 
und damit entweder 0 oder PR”) s7- Es findet also eine Normierung 
RÈIERD PTR ) 


auf die Summe der Wahrscheinlichkeiten der Relationen, die die Beobachtung 
des Angreifers zulassen, statt. 


Beobachtungen durch das Datenschutzauskunftssystem Der zentrale An- 
greifer ° kann ohne das Datenschutzauskunftssystem keine Beobachtungen 
machen, sondern muss sich vollständig auf das Hintergrundwissen auf Grund- 
lage des Verfahrensverzeichnisses verlassen. Er ist jedoch der einzige Angreifer, 
der mit Hilfe des Datenschutzauskunftssystems weitere Beobachtungen machen 
kann (Beobachtungsereignis I’). Der Systemangreifer $ hat nur Einsicht in 
die Provenance der sowieso bei ihm stattfindenden Verarbeitungsprozesse. Für 
ihn ist A(XY, I’) = A(XP,T)=1. 


Bei der Registrierung neu erhobener personenbezogener Daten im zentralen 
Verzeichnis lernt der zentrale Angreifer die Quelle der personenbezogenen 
Daten und den Ort der ersten Verarbeitung im Unternehmen kennen. Sei sọ die 
Quelle des Datums und ¢,, das erhebende System. Analog zu J ergibt sich eine 
Likelihood von 


P(T | RÈ) 2E t für (S0; Sk) € RG 

0, für (So, Sk) ¢ RÈ 
Beispiel. Die meisten Daten (dı bis dy, und di3 bis dıg) wurden durch den 
Onlineverkauf sz beim Betroffenen sı erhoben. Die IBAN wurde dagegen vom 
Kundenservice sę beim Betroffenen erhoben. Nur die Empfehlung dig kam 
aus einer anderen externen Quelle sg zum Onlineverkauf. Die Rechnung do 
wurde wie im Verfahrensverzeichnis vorgesehen im Onlineverkauf erzeugt. Die 
Beobachtung bestätigt nur bereits vorhandenes Wissen. 
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Als Ergebnis lassen sich jeweils die A-posteriori-Wahrscheinlichkeiten und 

der abgeleitete Grad der Unverkettbarkeit für X” und XY nach dem im 

Abschnitt 9.9 beschriebenen Verfahren bestimmen: 

P(RP | T’) = PU | RP )P(RP) = P | RP )P(RP) 
Pr) roere PUI’ | RP’) 


P(RY | I’) = >> P(R? | I’) 


RPERP|RP=,RY 


A(x? r) = Erzene P(R | 1) loga P(RP | 7) 
? S Roer’ P(RP) log, P(RP) 

A(x? r) = Leavers PIR |T) logy PRY | 7) 
X rrer» P(RY) logs, P(RY) 


9.9 Implementierung 


Wie bereits im vorherigen Abschnitt erwähnt, ist die Wahrscheinlichkeitsver- 
teilung für die Relation RF auch schon bei wenigen Systemen, Daten und 
Datentypen nicht mit akzeptablem Aufwand an Zeit und Speicher vollstän- 
dig berechenbar. Allerdings ist eine approximative Lösung möglich. Sind die 
Wahrscheinlichkeitsmatrizen nur spärlich mit Fortschrittswahrscheinlichkeiten 
belegt, ballt sich die Wahrscheinlichkeitsmasse bei denjenigen Kandidaten- 
relationen, die einen Fluss entlang des Verarbeitungsprozesses vorsehen. 
Kandidatenrelationen, die kaum Flüsse im Verarbeitungsprozess vorsehen, 
bilden den „Long Tail“ der Verteilung. Ihr Gewicht bei der Berechnung der 
Entropie ist gering. Würde man die Entropie anhand einer Stichprobe numerisch 
abschätzen, würden die Elemente des „Long Tail“ nur sehr selten auftreten. 
Ein naiver Schätzer H (X) = —)0, bi log, Pi, mit p; = 5 und n; als der 
Häufigkeit von RP in der Stichprobe und N = 5°, n; als deren Größe, würde 
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die Entropie systematisch unterschätzen und sich der tatsächlichen Entropie 
von unten annähern. ! 


Diesen Umstand kann man sich bei der Berechnung der Entropie aus den 
Wahrscheinlichkeitsmatrizen zunutze machen, indem man systematisch zuerst 
die wahrscheinlicheren Kandidaten in die Berechnung aufnimmt und den „Long 
Tail“ nur bis zu einem gegebenen Schwellwert 7 erschließt. Die Wahrscheinlich- 
keiten ergeben sich aus dem Wahrscheinlichkeitsbaum (Abbildung 9.4). Durch 
Tiefensuche in diesem Baum kann die Entropie, ausgehend vom Startsystem, 
approximativ erschlossen werden. 


Algorithmus 16: computeP(R7 | <,0) 


1 node + DecisionTree(s, #).getRootNode 
2 while node.hasNext do 
3 while node.hasChild ^ node.getProb > T do 
| node + node.pollNextNode 
end 
node.touchChildNodes 
result + result U {getMostProbableR (node.getState), 
node.getProb} 
8 node «+ node.pollNextNode // poll parent node 
9 end 
10 return result 


na u» 


Algorithmus 16 zeigt das grundsätzliche Vorgehen. Der Baum wird solange 
durchlaufen, bis der gegebenen Schwellwert unterschritten wird (Zeile 3). Ist 
noch kein Blatt erreicht, wird der übrige Teilbaum nicht weiter durchsucht 
(Zeile 6). Die gesuchte Wahrscheinlichkeit ergibt sich direkt aus dem Baum. 
Bei Blättern gilt das gleiche für die Relation. Wurde die Schleife aufgrund 
des Schwellwerts abgebrochen, muss noch die Relation mit der höchsten 


! Bonachela/Hinrichsen/Müoz 2008. 
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0,0904 < T 


0,98 


Abbildung 9.4: Wahrscheinlichkeitsbaum für 014, ausgehend von sı, mit angedeuteter Tiefen- 
suche (erste, zweite und dritte Iteration sowie die Suche nach dem jeweiligen 
Repräsentanten) für 7 = 0,1 
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Wahrscheinlichkeit als Repräsentant des ganzen Teilbaums ausgewählt werden 
(Zeile 7). Der übrige Teilbaum wird nicht weiter berücksichtigt (Verzweigungen 
unterhalb der orangenen Knoten in Abbildung 9.4). 


Beispiel. Tabelle 9.2 enthält die berechneten Ergebnisse für unterschiedliche 
Schwellwerte. Die Annäherung von unten ist deutlich sichtbar. Dem Betroffenen 
könnte ein Mindestgrad an Unverkettbarkeit von 0,94 bzw. 0,90 garantiert 
werden. 


Tabelle 9.2: Approximierte Werte für die Entropie und den Grad der Unverkettbarkeit der 
Relationen RP und RY für unterschiedliche Schwellwerte 7 


T H(X® H(X, I) A(X>, I) H(X”)  H(XY,I) A(X°%,r) 
10-1 125,8201 114,9513 0,8927 96,2104 85,8917 0,9136 
1072 139,5569 128,8865 0,9235 103,6033 92,4655 0,8925 
10-3 149,4219 139,3821 0,9328 107,1627 96,1635 0,8974 
1074 156,1207 147,2097 0,9429 109,1815 98,5819 0,9029 
10-5 157,3259 148,4618 0,9436 109,4951 98,8992 0,9032 
1076 159,4152 150,9697 0,9470 109,9215 99,4427 0,9046 
10-7 159,6693 151,2301 0,9471 109,9721 99,4967 0,9047 


9.10 Interpretation und Anwendung der Metrik 


Die folgenden Abschnitte verdeutlichen (1) die Bedeutung des Hintergrund- 
wissens für die Metrik, (2) die Relevanz der Metrik für das Datenschutzaus- 
kunftssystem und (3) die Anwendung der Metrik zum Systemvergleich. 


9.10.1 Berücksichtigung des Hintergrundwissens 


Im Abschnitt 9.3 wurde bereits ausgeführt, dass der negative Einfluss des Da- 
tenschutzauskunftssystems auf die Unverkettbarkeit bei Nichtberücksichtigung 
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des Hintergrundwissens als Teil des A-Priori-Wissens systematisch tiberschatzt 
würde. Alle Beobachtungen und das mögliche Angreiferwissen würden auf 
das A-posteriori-Wissen verlagert. Der Grad der Unverkettbarkeit würde viel 
zu niedrig angegeben werden. 


Die Verlagerung des Hintergrundwissens in die Modellierung des A-posteriori- 
Wissens wäre außerdem Grundsätzlich fragwürdig. Hintergrundwissen fällt 
nicht bei Einsatz eines Datenschutzauskunftssystems plötzlich vom Himmel. 


Wird das Hintergrundwissen des Angreifers weder a priori noch a posteriori 
berücksichtigt, gibt es sogar Verarbeitungssituationen, in denen die Unver- 
kettbarkeitsmetriken zu einer grundsätzlich falschen Interpretation verleiten 
würden. Aus Gründen der Vereinfachung wird zur Erläuterung folgendes 
Minimalbeispiel verwendet: 


Beispiel. Gegeben sei eine Situation mit einem personenbezogenen Datum 
d = ds der einzigen Kategorie 0 = 0; (Geburtsdatum) und den drei Syste- 
men Sa = Sı (Alice Fox), Ss» = sy (Vertrieb — Onlineverkauf) und Se = Ss 
(Kundenbetreuung). 


Der zentrale Angreifer f° lernt demnach durch das Datenschutzauskunftssys- 
tem, ob das Geburtsdatum vom Vertrieb oder vom Kundenservice bei Alice 
Fox erhoben wurde. Dies ist gleichbedeutend damit, ob ein Fluss von Sa nach 
Sp oder von Sa nach Se stattgefunden hat (r12 = 1 bzw. rız = 1). 


Ohne jedes Hintergrundwissen ergibt sich,' egal welchen der beiden Flüsse der 
Angreifer lernt, ein Grad der Unverkettbarkeit für die Datenflussrelation von 


H(X |I) log (2k7l’-1) 2-1 8 
A x? N= = 2 = = z 0,8889. 
aad Hmax( XP) log, (21°) 32 9 o? 


! Würde man das Hintergrundwissen als A-posteriori-Wissen miteinbeziehen, würde eine Dif- 
ferenzierung zwischen den beiden beobachteten Flüssen zustande kommen. Resultat wäre ein 
systematisch unterschätzter Grad der Unverkettbarkeit von A(X” ,I’) ~ 0,0484 beziehungs- 
weise A(X ,I’’) ~ 0,1119. 
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Ganz anders fällt die Bewertung aus, wenn Hintergrundwissen gemäß den 
Erläuterungen der vorangegangenen Abschnitte miteinbezogen wird. 


Beispiel. Sa ist das Herkunftssystem von 0. Das Verfahrensverzeichnis sieht 
einen Datenfluss von Sa zu Sp vor. Fortschrittsquote und Fehlerwahrschein- 
lichkeit werden, wie gehabt, mit w = 0,9 und o = 0,02 angenommen. Die 
Flussmatrix sieht dann wie folgt aus: 


1 0,9 0,02 
Wo, =| 0,02 1 0,02 
1 002 1 


Daraus ergibt sich eine A-priori-Entropie für den Angreifer von H(X") = 
0,8757. 


Die A-posteriori-Entropie hängt davon ab, welche Beobachtung gemacht wurde. 
Wird ein Fluss von von Sa nach & festgestellt (I’), ergibt sich H(X", I’) = 
0,4355 und resultierend A(X" ,I’) ~ 0,4974. 


Wird dagegen ein Fluss von Sa nach gs. erfasst (I”), steigt die A-posteriori- 
Entropie sogar. Die Beobachtung ist der A-priori-Annahme entgegengesetzt. 
Aus einem Wert von H (XP, I”) ~ 1,007 ergibt sich ein Grad der Unverkett- 
barkeit von A(X® I”) = 1,15. Nach der Normierung gemäß Abschnitt 9.4 
bleibt ein normierter globaler Grad der Unverkettbarkeit von ||A|| = 1. 


Folglich unterscheidet sich der resultierende Grad der Unverkettbarkeit für den 
Betroffenen, je nach tatsächlichem Datenfluss, deutlich. In einem größeren 
Szenario wäre der Unterschied weitaus geringer, da eine einzelne Bobachtung 
nicht so sehr ins Gewicht fällt. Nichtsdestoweniger gilt jedoch, dass das A- 
priori-Hintergrundwissen eine Differenzierung erlaubt, die sonst nicht möglich 
wäre. Der Grad der Unverkettbarkeit ist ohne Hintergrundwissen, unabhängig 
von der tatsächlichen Qualität der Beobachtung des Angreifers, immer gleich. 


Zusammenfassend lässt sich feststellen, dass die modellierte Einbeziehung des 
Hintergrundwissens nicht nur einen quantitativen Unterschied macht, sondern 
auch einen qualitativen. 
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9.10.2 Einbindung der Metrik in das 
Datenschutzauskunftssystem 


Der Grad der Unverkettbarkeit gemäß der vier Metriken kann dem Betroffenen 
als Anhaltspunkt dafür dienen, welchen Einfluss ein Datenschutzauskunfts- 
system auf die Profilbildungsmöglichkeiten innerhalb des datenverarbeitenden 
Unternehmens hat. Die präzise Angabe des Grads der Unverkettbarkeit bietet 
dem Betroffenen die Möglichkeit, selbst darüber zu entscheiden ob er der 
Transparenz (dem Auskunftssystem) oder der Unverkettbarkeit seiner Daten 
einen höheren Stellenwert einräumt. Zu diesem Zweck werden die Werte der 
Metriken auf der Auskunftsplattform PrivacyInsight visualisiert. Kapitel 10 
beschreibt, wie die Metriken eingebunden werden und welche Optionen sich 
dem Betroffenen bieten. In der Nutzerstudie in Kapitel 12 wird geschildert, 
wie sich Probanden bei einer Konfrontation mit der Metrik verhalten. 


Neben der implementierten Einbindung auf der Auskunftsplattform ist es 
auch denkbar, die Metrik bereits bei der Erhebung personenbezogener Daten 
einzubinden. Eine clientseitige Vorausberechnung könnte in einer Weban- 
wendung realisiert werden. Die Metrik würde dann den Wissenszuwachs der 
am Datenschutzauskunftssystem beteiligten Stellen durch die Datenerhebung 
repräsentieren. Der Betroffene könnte a priori entscheiden, ob er zunächst das 
Datenschutzauskunftssystem für sich deaktivieren will oder nicht. 


Die Metriken stellen jedoch nur den Wissenszuwachs durch die Provenance, 
nicht den Wissenszuwachs durch die erhobenen personenbezogenen Daten 
selbst dar. Bei Berücksichtigung des Inhalts müsste der Einfluss desselben auf 
die Verkettungsmöglichkeiten bestimmt werden. Eine solche Inhaltsanalyse ist 
nur schwer in allgemeiner Form umzusetzen und wird durch die vorgestellten 
Verfahren nicht abgedeckt. 


9.10.3 Systemvergleich mit Hilfe der Metrik 


Die Metrik ist auch nur eingeschränkt für den Vergleich von Architekturen vor 
der Realisierung eines Datenschutzauskunftssystems geeignet. Da immer ein 
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konkreter Prior und Posterior herangezogen wird, ist das Ergebnis der Metrik 
vom konkreten Szenario und Betrachtungszeitpunkt abhängig. Für in ihrer 
Struktur deutlich unterschiedliche Architekturen kann die Metrik dennoch eine 
Abschätzung bieten. 


Beispielhaft könnte eine Alternativarchitektur zur, in dieser Arbeit vorge- 
stellten,! Architektur vorsehen, die gesamte Provenance auf einem zentralen 
Server zu speichern (Alternative 1). Da dieses Serversystem Einblick in alle 
Datenflüsse hätte, würde der Grad der Unverkettbarkeit, die Unsicherheit des 
Angreifers, für die Verarbeitungsrelation und die Datenflussrelation bei 0 liegen. 
Solange weiterhin nicht die konkreten personenbezogenen Daten, sondern nur 
Pseudonyme zentral gespeichert würden, würde der Grad der Unverkettbarkeit 
für die Identifikationsrelation und die Verknüpfungsrelation zwar niedriger als 
in der tatsächlich realisierten Architektur liegen,” jedoch zumindest nicht bei 0. 


Die gleiche Situation ergibt sich bei der redundanten Speicherung der Proven- 
ance gemäß der beiden in Kapitel 8 erwähnten Konzepte Cassandra-Cluster und 
verteilte Hashtabelle (Alternative 2). Bei einem Cassandra-Cluster kann jedes 
System auf die gesamte Provenance zugreifen. Beim Konzept der verteilten 
Hashtabelle kann der zentrale Server, der die Schlüssel für die gesamte Proven- 
ance kennt, auf die gesamte Provenance, ohne Einwirkung des Systems, aus 
dem die Provenance ursprünglich stammt, zugreifen. Der zentrale Server hat 
somit effektiv den gleichen Wissensstand wie bei einer zentralen Speicherung. 


Die interessanteste Vergleichsarchitektur für die, in dieser Arbeit vorgestellte, 
Architektur ist die von Insynd (Alternative 3).° Aufgrund der Verschlüsselung 
der Provenance auf den Logservern und der Schlüsselgewalt durch den Betroffe- 
nen, würde der Grad der Unverkettbarkeit für die Verarbeitungsrelation und die 
Datenflussrelation bei 100 % liegen. Da alle Systeme den öffentlichen Schlüssel 
des Betroffenen kennen müssen, ist die Situation für die Identifikationsrelation 
und die Verknüpfungsrelation differenzierter. Diese Metriken können nur für 


! Vgl. Kapitel 8.2. 

2 Anhand der Datenflüsse kann auf die Kategorie der personenbezogenen Daten geschlossen 
werden. 

3 Pulls/Peeters 2015. 
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ein konkretes Szenario zu einem festgelegten Zeitpunkt bestimmt werden. Zum 
Vergleich wird wie gehabt das durchgängige Minimalbeispiel gewählt. 


Angreifer ist bei der Insynd-Architektur nur /°. Einen zentralen Angreifer gibt 
es nicht. Auch wenn es einen zentralen Logserver gibt, liegt die Provenence 
dort nur verschlüsselt vor. Der Systemangreifer, in dessen System die meisten 
personenbezogenen Daten verarbeitet werden, ist der Angreifer der durch die 
Schlüsselzuordnung im ungünstigsten Fall am meisten lernen kann. 


Im besten Fall! ist durch den Inhalt der personenbezogenen Daten in ei- 
nem datenverarbeitenden System direkt klar, zu welchem Betroffenen die 
Daten gehören. Die Schlüsselverwaltung spielt in diesem Fall keine Rolle. 
Der Grad der Unverkettbarkeit liegt für die Identifikationsrelation und die 
Verknüpfungsrelation bei jeweils 100 %. 


Im ungünstigsten Fall ist durch den Inhalt und die Struktur der Datenspei- 
cherung keine Identifikation des Betroffenen möglich. Ebenso ist es für den 
Angreifer ausgeschlossen, herauszufinden, welche personenbezogenen Daten 
zum selben Betroffenen gehören. In diesem Fall wird der Angreifer beim 
Einsatz eines Datenschutzauskunftssystems mit /nsynd neu lernen, welche 
personenbezogenen Daten zum selben Betroffenen gehören.” Begründet liegt 
dies in dem Erfordernis, alle personenbezogenen Daten eines Betroffenen mit 
dessen öffentlichem Schlüssel zu verschlüsseln. 


Beispiel. Das System, das bei AdBokis die meisten personenbezogenen Daten 
verarbeitet, ist der Onlineverkauf im Vertrieb (s7). Dort werden 18 personenbe- 
zogene Daten von Alice (d; bis dig mit Ausnahme von dı>) verarbeitet. 3 Bei der 
Berechnung der Anzahl der A-posteriori-Kandidatenrelationen für die Verknüp- 
fungsrelation steht die Zusammengehörigkeit der 18 Daten bereits im Vorhinein 


! Im Hinblick auf die Auswirkungen eines Datenschutzauskunftssystems mit Insynd, nicht für den 
Betroffenen. 

2 Sind die Schlüssel nicht pseudonymisiert, sondern mit einem Identifikator verknüpft, ist sogar 
klar, zu welchem Betroffenen die Daten gehören. 

3 Peter bleibt in diesem Beispiel zur Vereinfachung außen vor. 
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fest. Sie können wie ein Datum behandelt werden. Damit reduziert sich die An- 
zahl der Kandidatenrelationen auf |R=| = Y} _o S13, = 2"? = 4096. Folg- 


912 


lich ist der resultierende Grad der Unverkettbarkeit A(X”,I) = eee a = 
35 = 0,4138.” 


Das Vorgehen für die Identifikationsrelation ist äquivalent. Die zusammengehö- 
rigen Daten können nur gemeinsam zu einem Betroffenen gehören. Die reduzier- 
te Anzahl der Kandidatenrelationen liegt bei (R< | = 2!? = 8192 und der resul- 


tierende Grad der Unverkettbarkeit ist A(X“,I) = ae = = 35 x 0,4333. 


Damit sind beide Werte im ungünstigsten Fall deutlich niedriger als bei dem 
in dieser Arbeit verwendeten System. Tatsächlich würden die Werte jedoch 
irgendwo zwischen 100 % und den oben berechneten Werten liegen. 


Zusammenfassend kann festgehalten werden, dass man sich für Jnsynd ent- 
scheiden würde, falls Prozesswissen der entscheidende Faktor ist und man den 
Betroffenen in den Schlüsselerzeugungsprozess einbinden kann. Zieht man die 
Verknüpfung unterschiedlicher personenbezogener Daten eines Betroffenen 
als Hauptfaktor heran, hängt die Bewertung davon ab, welche Schlüsse sich 
bereits ohne das Datenschutzauskunftssystem in den erhebenden Systemen 
ziehen lassen. Im Beispiel fließen fast alle Daten des Betroffenen gemeinsam 
nach ¢7. Allein aufgrund dieser Strukturinformation ist davon auszugehen dass 
der Systemangreifer bereits a priori mit hoher Sicherheit sagen kann, welche 
personenbezogenen Daten zusammengehören. Es kann indes nicht abschließend 
festgestellt werden, ob Insynd oder die in dieser Arbeit verwendete Architektur 
die bessere ist. 


9.11 Zwischenfazit 


Die wissenschaftlichen Beiträge dieses Kapitels lassen sich wie folgt zu- 
sammenfassen: (1) Die Formulierung einer Unverkettbarkeitsmetrik unter 


! Vgl. Abschnitt 9.8.1. 
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Beriicksichtigung beliebiger Relationen, (2) die Beriicksichtigung und Be- 
stimmung des Hintergrundwissens und der Beobachtungen des Angreifers 
(,,Verketters“), (3) eine Instantiierung der Metrik für das Szenario eines Daten- 
schutzauskunftssystems und (4) eine Heuristik zur Berechnung der Metrik in 
der Praxis. 


Die in diesem Kapitel vorgestellte Unverkettbarkeitsmetrik beriicksichtigt 
die vier Faktoren Entitäten, Verkettungsrelation, Verketter und betrachtetes 
System. Sie beruht auf informationstheoretischen Überlegungen und erfüllte 
alle in Abschnitt 9.4 aufgeführten formalen Anforderungen an Metriken für 
Unverkettbarkeit. 


Im Kontext eines Datenschutzauskunftssystems wurde die Metrik in vier 
Varianten instanziiert, die in Übereinstimmung mit Konstruktionsziel £5 alle 
Aspekte der Verarbeitung der Personal-Data-Provenance abdecken. 


Es ist nicht realistisch, nur Angreifer ohne Hintergrundwissen anzunehmen. 
Deshalb wurden für die Überlegungen in diesem Kapitel Angreifer mit Hin- 
tergrundwissen eingeführt. Das Hintergrundwissen stützt sich vor allem auf 
die Annahme, dass unternehmensinternen Angreifern das Verfahrensverzeich- 
nis bekannt ist. Das Hintergrundwissen wurde formalisiert und die darauf 
basierende Bestimmung der A-priori- und A-posteriori-Entropie erläutert. 


Die resultierende Metrik ermöglicht eine Differenzierung abhängig von den 
Beobachtungen des Angreifers. Berücksichtigt wurden ein Systemangreifer 
und ein zentraler Angreifer. Weitere Angreifer wurden nicht betrachtet. Im 
Allgemeinen sind solche Beobachtungen relevant, die Rückschlüsse auf die be- 
trachteten Relationen zulassen. Im Szenario des Datenschutzauskunftssystems 
sind dies Informationsflüsse und Metainformationen über den Personenbezug. 


Die Annahme unabhängiger Datenflüsse ist wesentliche Voraussetzung für 
die Berechenbarkeit der Metrik. Für die Bestimmung der Entropie je Datum 
wurde eine Heuristik entwickelt, die sich das asymptotische Verhalten von 
Entropieschätzern zu Nutze macht. Dadurch kann die Metrik in konkreten 
Praxisszenarien bestimmt werden. 
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Eingeschränkt kann die Unverkettbarkeitsmetrik für den Vergleich von Sys- 
temarchitekturen verwendet werden. Wichtiger ist jedoch die Information des 
Betroffenen. Die Unverkettbarkeitsmetrik macht die Auswirkungen des Da- 
tenschutzauskunftssystems für den Betroffenen erkennbar. Er kann sich selbst 
entscheiden, ob er für das Mehr an Transparenz bereit ist, den zusätzlichen 
Verlust an Unverkettbarkeit zu akzeptieren. Das nachfolgende Kapitel wird 
diesen Gedanken weiter ausführen. 
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Ziel eines integrierten Datenschutzauskunftssystems ist es, den Betroffenen 
mit seiner vollen Entscheidungsautonomie in den Mittelpunkt zu stellen. Zur 
Entscheidungsfreiheit des Betroffenen gehört auch, aus Bedenken bezüglich 
der Verkettung von Daten und Verarbeitungsbeziehungen, auf das Provenance- 
Tracking und daraus resultierend auf die elektronische Auskunftserteilung zu 
verzichten. In Abschnitt 10.1 wird erörtert, ob eine solche freie Entscheidung 
zwischen Transparenz und Unverkettbarkeit im Rahmen des Datenschutzrechts 
möglich ist. 


Ein Datenschutzauskunftssystem könnte beispielsweise eine Funktion vorsehen, 
mit der der Betroffene das Provenance-Tracking jederzeit abschalten kann. 
Dadurch reduziert sich für ihn die Transparenz, aber gleichzeitig erhöht sich 
für ihn die Unverkettbarkeit zukünftiger Datenverarbeitungsvorgänge. Wie die 
Auskunftsplattform PrivacyInsight aufgebaut ist und an welcher Stelle eine 
solche Option integriert ist, stellt Abschnitt 10.3 vor. 


Es ist außerdem Teil der Betroffenenautonomie, selbst zu bestimmen, wer die 
eigenen personenbezogenen Daten zu einem bestimmten Zweck verarbeitet. 
Die DSGVO hat aus diesem Grund ein Recht auf Datenübertragbarkeit neu 
eingeführt. Der Zusammenhang zwischen Datenübertragbarkeit und Auskunft 
wird in Abschnitt 10.2 erläutert. 
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10.1 Freie Entscheidung zwischen Transparenz 
und Unverkettbarkeit 


Ein Datenschutzauskunftssystem ist ein entscheidendes Werkzeug, um die 
Transparenz des Umgangs mit personenbezogenen Daten zu verbessern. Auf 
der anderen Seite führt ein Datenschutzauskunftssystem zu einer zweckgebun- 
denen, aber doch zusätzlichen Verwendung personenbezogener Daten. Für die 
Auskunft muss die Personal-Data-Provenance so verarbeitet und gespeichert 
werden, dass sie zum Zeitpunkt der Auskunftserteilung zu einem Gesamtbild 
des Betroffenen zusammengefügt werden kann.! Aus diesem Grund kann es 
durchaus Betroffene geben, die lieber auf die Möglichkeit einer elektronischen 
Auskunftserteilung verzichten würden. Abhängig von der Bewertung der Er- 
gebnisse der Unverkettbarkeitsmetriken aus Kapitel 9 könnten sie zum Schluss 
kommen, dass eine informative Auskunft die Profilbildungsmöglichkeiten 
durch das Provenance-Tracking nicht aufwiegt. 


Allerdings scheint solch ein Verzicht auf das Recht auf Auskunft im Daten- 
schutzrecht nicht vorgesehen. $ 6 Abs. 1 BDSG kodifiziert die Unabdingbarkeit 
des Rechts auf Auskunft. 


Das Recht des Betroffenen auf Auskunft kann nicht durch Rechtsgeschäft 
ausgeschlossen oder beschränkt werden. Die Dispositionsbefugnis des Betrof- 
fenen wird im Interesse des Betroffenen eingeschränkt.” Es soll verhindert 
werden, dass der Betroffene seine Rechte für das sprichwörtliche Linsengericht 
aufgibt.’ 


Die Unabdingbarkeit des Rechts auf Auskunft gilt unabhängig von der Form des 
Rechtsgeschäfts.* „Ein Rechtsgeschäft ist auf die Herbeiführung eines rechtli- 
chen Erfolges gerichtet, der nach der Rechtsordnung eintritt, weil er gewollt 


l Leucker, PinG 2015, 195 (198) sieht bereits Risiken durch die Strukturierung für das Recht auf 
Datenübertragbarkeit. 

2 BT-Drs. 11/4306, 41. 

3 Tangens 2008, 140 nach 1. Mose 25, 29-34. 

4 Dix in: Simitis, BDSG 2014, § 6 Rn. 15. 
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ist.“! Ein Rechtsgeschäft besteht aus einer oder mehreren Willenserklärungen, 
die, gegebenenfalls in Verbindung mit weiteren Tatbestandsmerkmalen, die 
Rechtsfolge herbeiführen.” Darunter fällt auch die einseitige Willenserklärung 
des Betroffenen zum freiwilligen Verzicht auf die Nutzung des Datenschutz- 


auskunftssystems. 


Eine Beschränkung des Rechts auf Auskunft ist immer eine Änderung zum 
Nachteil des Betroffenen.* Einer Erweiterung oder Verstärkung des Auskunfts- 
anspruchs zu Gunsten des Betroffenen steht die Vorschrift nicht entgegen.* 
Die Wahl zwischen Auskunftsplattform und Unverkettbarkeit ist keine solche 
Erweiterung, da sie gerade der Abwägung unterschiedlicher Nachteile durch 
den Betroffenen bedarf. Der Verzicht auf die elektronische Form der Auskunft 
ist zwar kein Verzicht auf die Auskunft an sich. In komplexen Informati- 
onssystemen ist jedoch ohne ein, wie in den Kapiteln 5 bis 8 dargestelltes, 
Informationsflusstracking keine vollständige Auskunft möglich. Insofern ist 
ein Rückfall auf die manuelle Teilauskunft eine Beschränkung des Rechts auf 
Auskunft. 


Die Einschränkung des Dispositionsrechts geht davon aus, dass dem Betrof- 
fenen sein Recht abgekauft wird oder er, aufgrund anderer datenschutzferner 
Erwägungen, auf seine Rechte verzichtet. Die Regelung erwartet nicht, dass dem 
Betroffenen Nachteile in der Wahrnehmung anderer Datenschutzrechte entste- 
hen. Insofern ist die Abwägung zwischen Transparenz und Unverkettbarkeit 
regelungsuntypisch. 


Auch im Datenschutzrecht gilt der Grundsatz der Privatautonomie. Die Privat- 
autonomie als Teil der allgemeinen Handlungsfreiheit aus Art. 2 Abs. 1 GG 
schützt die Selbstbestimmung privater Akteure im Zivilrechtsverkehr.° Eingrif- 
fe in den Schutzbereich der Privatautonomie sind zulässig, um strukturellen 
Macht- oder Informationsasymmetrien zu begegnen, die dazu führen, dass eine 


! Völzmann-Stickelbrock/Ahrens in: Prütting/Wegen/Weinreich, BGB 2015, Vor $ 116 ff Rn. 1. 
2 Völzmann-Stickelbrock/Ahrens in: Prütting/Wegen/Weinreich, BGB 2015, Vor § 116 ff Rn. 3. 
3 Dix in: Simitis, BDSG 2014, § 6 Rn. 21. 

4 Dix in: Simitis, BDSG 2014, $ 6 Rn. 22; Gola/Schomerus, BDSG 2015, $ 6 Rn. 4. 

5 BVerfGE 89, 214 (231); Dreier in: Dreier, GG 2013, Art. 1 I Rn. 62. 
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Partei den Vertragsinhalt einseitig bestimmt. ! Ziel dieser Eingriffe muss der 
im Sozialstaatsprinzip (Art. 20 Abs. 1, Art. 28 Abs. 1 GG) wurzelnde Schutz 
vor Fremdbestimmung sein.” 


Die Regelungen des nicht-öffentlichen Datenschutzes gehen von solch einer 
Machtasymmetrie aus. Ist der Betroffene jedoch, analog zur Einwilligung, 
fundiert informiert, und ist seine Entscheidung frei und unbeeinflusst, dann ist 
ein Eingriff in die Privatautonomie nicht mehr gerechtfertigt. Dem Betroffenen 
ist ein Dispositionsrecht zuzugestehen.* 


Ein Opt-out aus der elektronischen Auskunftserteilung durch ein Datenschutz- 
auskunftssystem muss sich an diesen Kriterien messen lassen. 


Die Entscheidung über das Opt-out ist analog zu $ 4a Abs. 1 S. 2 BDSG und 
Art. 4 Nr. 11 i. V.m. ErwGr 32 DSGVO nur möglich, wenn sie informiert 
erfolgt. Die Entscheidung erfolgt informiert, wenn der Betroffene rechtzeitig 
und umfassend über die Konsequenzen der Handlungsalternativen unterrichtet 
wurde. Der Anlass und die Folgen der Entscheidung müssen ersichtlich wer- 
den.® Das Datenschutzauskunftssystem informiert den Betroffenen durch den in 
Abbildung G.10 dargestellten Text über die Konsequenzen der Auskunft und die 
Bedeutung der, in Kapitel 9 vorgestellten, Unverkettbarkeitsmetriken. Die Un- 
verkettbarkeitsmetriken sind ein objektiver Maßstab für das Profilbildungsrisiko 
durch das Datenschutzauskunftssystem. Den entstandenen Transparenzgewinn 
kann der Betroffene durch die Nutzung des Datenschutzauskunftssystems 
evaluieren. 


Der freien Entscheidung liegt die Vorstellung vom Menschen als selbstbe- 
stimmtem, geistig-sittlichem Wesen zu Grunde.’ Der Betroffene entscheidet 


1 BVerfGE 81, 242 (255); BVerfGE 89, 214 (232); BVerfGE 103, 89 (100 f.). 

2 Dreier in: Dreier, GG 2013, Art. 1 I Rn. 63. 

3 Vgl. Kapitel 2.1.2 zur Drittwirkung der Grundrechte. 

4 In der DSGVO findet die grundsätzliche Unabdingbarkeit der Auskunft gar keine Erwähnung 
mehr. 

5 Simitis in: Simitis, BDSG 2014, $ 4a Rn. 70. 

6 Simitis, a.a.O. 

7 BVerfGE 45, 187 (227). 
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frei,! wenn er im Vollbesitz seiner geistigen Kräfte? und ohne Zwang? aus min- 
destens zwei Handlungsalternativen* auswählt. Beides ist beim vorgesehenen 
Opt-out grundsätzlich gegeben. 


Zur freien Entscheidung gehört auch, dass der Betroffene jederzeit berechtigt 
ist, eine einmal gewählte Option nachträglich, mit Wirkung für die Zukunft, 
wieder zu ändern.’ Allerdings scheidet nach Beginn einer Verarbeitung eine 
Änderung dann aus, wenn es der verantwortlichen Stelle objektiv nicht mehr 
möglich oder nicht zuzumuten ist, die Verarbeitung der Daten zukünftig gemäß 
der neuen Handlungsvorgabe durchzuführen. Dies kann beispielsweise bei 


anonymisierten oder pseudonymisierten Daten der Fall sein.® 


Dem Opt-out aus der elektronischen Auskunftserteilung ist somit ein nachträg- 
liches Opt-In beizugesellen. Ein solches Opt-In führt dazu, dass zukünftige 
Verarbeitungsvorgänge personenbezogener Daten wieder elektronisch beaus- 
kunftet werden können. Da während der Opt-Out-Phase Speicherorte entstehen 
können, die sich einem zukünftigen Tracking entziehen, ist es der verantwort- 
lichen Stelle objektiv nicht mehr möglich, die Vollständigkeit der Auskunft 
bezüglich bereits erhobener personenbezogener Daten sicherzustellen. Für zu- 
künftig erhobene Daten kann allerdings eine Vollständigkeitsgarantie gegeben 
werden. 


Eine Entscheidung ist unbeeinflusst, wenn sie frei von Einwirkungen getroffen 
wird, die nichts mit dem datenschutzrechtlichen Gehalt der Entscheidung zu 
tun haben. Jenseits von Zwangsmaßnahmen können sowohl die verantwort- 
liche Stelle als auch Dritte durch flankierende Maßnahmen Einfluss auf die 
Entscheidung des Betroffenen nehmen. Eine Variante ist die Kopplung der 
Entscheidung an einen Vertragsschluss oder an monetäre Anreize. Eine solche 


! Art. 4 Nr. 11 DSGVO. 

? Analog zu den Anforderungen an eine Willenserklärung in $ 105 Abs. 2 BGB. 

3 Art. 2 Lit. h DSRL. 

4 Die „echte Wahl“ des ErwGr 42 DSGVO. 

5 Simitis in: Simitis, BDSG 2014, § 4a Rn. 94. 

6 Simitis in: Simitis, BDSG 2014, § 4a Rn. 98 und explizit Art. 7 Abs. 3 DSGVO. 
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Kopplung ist grundsätzlich unzulässig.! Eine ebenfalls unzulässige Maßnah- 
me ist die tendenziöse Darstellung der möglichen Handlungsalternativen.” 
Alle Handlungsalternativen müssen neutral und mit ihren jeweiligen Folgen 
dargestellt werden.* Ergänzend führt ein Abhängigkeitsverhältnis zwischen 
Betroffenem und verantwortlicher Stelle zu einer mittelbaren Beeinflussung des 
Entscheidungsprozesses.* Ein Opt-Out in der Arbeitnehmerdatenverarbeitung 
kann deshalb nicht erwogen werden. 


In der Gesamtschau ist ein informiertes Opt-out aus der elektronischen Aus- 
kunftserteilung durch ein Datenschutzauskunftssystem zulässig. Notwendige 
Voraussetzungen sind die objektive und vollständige Unterrichtung über die 
Konsequenzen der Alternativen sowie die Ermöglichung eines nachträglichen 
Opt-In. 


Entscheidend ist außerdem, dass die Konsequenz eines Opt-out kein vollständi- 
ger Verzicht auf jede Transparenz ist. Unterrichtungen und Benachrichtigungen 
können und müssen weiterhin erfolgen. Des Weiteren kann der Betroffene eine 
manuelle Teilauskunft verlangen, wenn er nach § 34 Abs. 1 S. 2 BDSG die 
Art und den Speicherort der personenbezogenen Daten, zu denen er Auskunft 
verlangt, näher bezeichnet. Eine vollständige Auskunft ist nach dem Opt-out 
jedoch ausgeschlossen, da die dafür erforderliche Verknüpfung fehlt. 


10.2 Das Recht auf Datenübertragbarkeit 


Das Recht auf Datenübertragbarkeit ist ein vollständige Neuschöpfung der 
DSGVO.? Da mit diesem Recht neue Vorstellungen einhergehen, wird, abwei- 
chend vom sonstigen Vorgehen, exponiert die künftige Rechtslage erörtert. 


l Simitis in: Simitis, BDSG 2014, § 4a Rn. 63 und explizit Art. 7 Abs. 4 DSGVO. 

? Beliebt im Zuge des Soft-Paternalismus. 

3 Wie in Kapitel 12.4 dargestellt, kann eine neutrale, stark formalisierte Metrik nicht von jedem 
Betroffenen einfach verstanden werden. Der Aspekt der Informiertheit leidet. 

4 Simitis in: Simitis, BDSG 2014, $ 4a Rn. 62. 

5 Laue/Nink/Kremer 2016, $ 4 Rn. 59; Kamlah in: Plath, BDSG/DSGVO 2016, Art. 20 Rn. 1; 
Paal in: Paal/Pauly, DSGVO 2017, Art. 20 Rn. 28. 
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Das Recht auf Datenübertragbarkeit ist in Art. 20 DSGVO geregelt und hängt 
eng mit dem Recht auf Auskunft zusammen, ist mit ihm jedoch nicht identisch. ! 
Gemäß Art. 15 Abs. 3 DSGVO steht dem Betroffenen eine Kopie seiner perso- 
nenbezogenen Daten zu. Im Auskunftsanspruch ist allerdings nicht festgelegt, in 
welcher Form diese Kopie auszuhändigen ist. Auf der anderen Seite umfasst das 
Recht auf Auskunft die in Kapitel 3.7 geschilderten Informationen. Das Recht 
auf Datenübertragbarkeit betrifft nur die gespeicherten personenbezogenen 
Daten, die der verantwortlichen Stelle vom Betroffenen bereitgestellt wurden. 
Ein personenbezogenes Datum wurde dann vom Betroffenen bereitgestellt, 
wenn die verantwortliche Stelle das Datum bei ihm erhoben hat.” 


Art. 20 Abs. 1 DSGVO fordert, dass der Betroffene die Kopie der perso- 
nenbezogen Daten in einem strukturierten, gängigen und maschinenlesbaren 
Format erhält. Ein Format ist strukturiert, wenn es eine festgelegte, für einen 
Computer oder einen Menschen verständliche Syntax besitzt. Ein Format ist 
gängig, wenn es standardisiert wurde und im Markt gebräuchlich ist.* Ein 
Format ist maschinenlesbar, wenn es automatisiert durch einen Computer 
interpretiert werden kann.” Kandidaten, die diese Voraussetzungen erfüllen, 


! Kamlah in: Plath, BDSG/DSGVO 2016, Art. 20 Rn. 2 sieht Art. 20 DSGVO als einen Spezialfall 
des Art. 15 DSGVO. 

2 Kamlah in: Plath, BDSG/DSGVO 2016, Art. 20 Rn. 6 fasst darunter nur die Stammdaten und 

in Rn. 7 weitergehend keine Daten, die der Betroffene zur Nutzung von technischen Features 

selbst eingegeben hat. Dieser engen Sichtweise kann nicht gefolgt werden. Sie widerspricht der 

wettbewerbs- und datenschutzrechtlichen Zielsetzung der Norm. 

Der Gesetzgeber lässt die Definitionen offen und auch die Kommentarliteratur äußert sich noch 

nicht — Laue/Nink/Kremer 2016, $ 4 Rn. 66; Kamlah in: Plath, BDSG/DSGVO 2016, Art. 20 

Rn. 8; Paal in: Paal/Pauly, DSGVO 2017, Art. 20 Rn. 19. Insofern stellen die hier eingeführten 

Definitionsversuche ein Novum dar. 

Nach ErwGr 55 DSGVO folgt daraus keine Pflicht zu technisch kompatiblen Datenverarbei- 

tungssystemen. 

Entspricht dem Begriff „elektronisch“ in Art. 15 Abs. 3 S. 3 DSGVO, so Schätzle, PinG 2016, 

71 (74). Darüber hinaus kann vertreten werden, dass aus dem Begriff folgt, dass die Semantik 

des Datenformats definiert sein muss. 


w 


A 
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sind die Extensible Markup Language (XML)! und die JavaScript Object 
Notation (JSON).” 


Das Recht auf Datenübertragbarkeit gilt gemäß Art. 20 Abs. 1 Lit. a DSGVO 
nur dann, wenn die Rechtsgrundlage der Datenverarbeitung Einwilligung oder 
Vertrag sind. Ist die verantwortliche Stelle durch Gesetz zur Datenverarbeitung 
verpflichtet, gilt das Recht auf Datenübertragbarkeit nicht. 


Anstelle dessen, dass der Betroffene eine Kopie seiner personenbezogenen 
Daten erhält, sollte es ihm nach Art. 20 Abs. 2 DSGVO ergänzend möglich 
sein, die personenbezogenen Daten direkt von einer verantwortlichen Stelle 
zu einer anderen tibermitteln zu lassen. Dieses weitere Recht steht unter dem 
Vorbehalt der technischen Machbarkeit. Diese ist objektiv anhand des Stands 


der Technik zu bestimmen.? 


Die Direktiibertragung und nahtlose Weiternutzung bei einer anderen verant- 
wortlichen Stelle ist nur dann möglich, wenn die verwendeten Formate der 
verantwortlichen Stellen kompatibel sind. Deshalb fordert ErwGr 68 DSGVO 
die Verantwortlichen dazu auf, gemeinsame interoperable Formate zu entwi- 
ckeln. Inkonsequenterweise halt ErwGr 68 gleichzeitig fest, dass sich daraus 
keine Pflicht begründen lässt „technisch kompatible Datenverarbeitungssysteme 
zu übernehmen oder beizubehalten.“ Dadurch sind Vermeidungsstrategien 
unwilliger verantwortlicher Stellen Tür und Tor geöffnet. 


Für das Datenschutzauskunftssystem bedeutet das Recht auf Datenübertragbar- 
keit zwei Dinge: Zum einen muss auf der Auskunftsplattform eine Download- 
möglichkeit der personenbezogenen Daten in einem Format, das die obigen 
Bedingungen erfüllt, angeboten werden. Zum anderen muss die Datenstruktur 
so aufgebaut werden, dass sie sich einfach an mögliche zukünftige Standards 
anpassen lässt. 


1 https://www.w3.org/XML/Core. 

2 https://tools.ietf.org/html/rfc7159 und http://www.ecma-international.org/publications/files/ 
ECMA-ST/ECMA-404.pdf. 

3 Laue/Nink/Kremer 2016, § 4 Rn. 65. 
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10.3 Möglichkeiten des Betroffenen auf der 
Auskunftsplattform PrivacyInsight 


Es ist nicht ausreichend, dem Betroffenen immer mehr Informationen und 
Wahlmöglichkeiten anzubieten. Ausufernde Konvolute textueller Informationen 
können und wollen die meisten Betroffenen nicht lesen. Nur durch eine 
knappe und übersichtliche Darstellung der Informationen in einem abgestuften 
Modell wird das Verständnis des Betroffenen gefördert.! Die im Rahmen 
dieser Arbeit entwickelte? Auskunftsplattform PrivacyInsight? bietet zum 
Einstieg eine knappe Übersicht und erlaubt bei Interesse ein stufenweises 
Eintauchen in weitere Informationen. Die Kernfunktion von PrivacyInsight ist 
die Visualisierung der Informationsflüsse, der Herkunft-Empfänger-Ketten. 


Der Betroffene soll seine Rechte auf Auskunft, Berichtigung, Löschung, 
Sperrung und Datenübertragung sowie die genannte Wahlmöglichkeit zwischen 
Transparenz und Unverkettbarkeit an einer Stelle gesammelt wahrnehmen 
können (Anforderung 47). Eine solche integrierte Sicht ist ein weiterer Aspekt 
der PrivacyInsight auszeichnet. 


PrivacyInsight ist eine Webanwendung.* Sie besteht von oben nach unten 
aus den drei Teilen Navigationsleiste, Visualisierung des Informationsflusses 
und Statusleiste (Abbildung 10.1). Nach Anmeldung über die vorgelagerte 
Anmeldemaske wird der Informationsfluss zunächst mit minimalen Details 
angezeigt. Am linken Fensterrand sind alle Datenquellen, am rechten Rand 
alle Senken dargestellt. Die verantwortliche Stelle wird als ein Knoten in der 
Fenstermitte repräsentiert. 


Links neben den Quellen und rechts neben den Senken befinden sich jeweils 
Icons für alle erhobenen beziehungsweise übermittelten personenbezogenen 
Daten. Die Icons sind abhängig von der Datenkategorie gestaltet. Dies soll 
das Wiederfinden bestimmter personenbezogener Daten erleichtern. Bei der 


! Robrecht 2015, 70. 

? Ein frühes Konzept findet sich bereits in Sommerfeld 2013. 
3 Im Kontext von Kühne 2016 entstanden. 

4 Bereits veröffentlicht in Bier/Kühne/Beyerer 2016. 
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Privacy Insight 
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Abbildung 10.1: Die Auskunftsplattform PrivacyInsight 


Auswahl eines Datums wird der Provenance-Baum für dieses Datum hervorge- 
hoben (Anforderung 52). Wird die Detailsicht für ein Datum geöffnet, ergibt 
sich dort die Möglichkeit das Datum einzusehen, zu exportieren, zu berichtigen, 
zu sperren oder zu löschen (Anforderungen 47, 48 und 49). Das eigentliche 
personenbezogene Datum wird erst beim Öffnen dieser Detailansicht aus den 
speichernden Systemen geladen. Die letzten beiden Optionen werden durch 
UC-Policies umgesetzt. 


Wie oben erwähnt sind in der Informationsflussvisualisierung zu Beginn nur 
die Erhebung und Übermittlung personenbezogener Daten dargestellt. Ver- 
arbeitung, Speicherung und interne Weitergabe sind hinter dem Knoten der 
verantwortlichen Stelle verborgen. Durch Anwählen (Anklicken oder Antip- 
pen) des Knotens öffnet sich die nächste Ebene in der Domänenhierarchie,! 
beispielsweise eine Sicht auf die einzelnen Abteilungen und die Informati- 
onsflüsse zwischen ihnen. Abhängig von den Vorgaben der verantwortlichen 
Stelle, insbesondere unter Berücksichtigung ihrer Betriebsgeheimnisse, kann 
die vollständige Domänenhierarchie bis auf IT-Systemebene aufgerufen oder 


! Siehe Anhang D. 
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sogar in Anwendungen hineingeschaut werden. Von besonderem Interesse für 
den Betroffenen sind Informationsflüsse zu Auftragsdatenverarbeitern. Diese 
werden im Provenance-Graphen gesondert hervorgehoben. 


Für jeden Knoten ist es möglich, ein Kontextmenü aufzurufen, um die in der 
entsprechenden Domäne, dem System oder der Abstraktionsschicht verarbei- 
teten oder gespeicherten Daten, gemeinsam mit dem jeweiligen Zweck der 
Verwendung, einzusehen. Kleine Icons machen deutlich, was mit den Daten 
im jeweiligen Knoten geschieht. In diesem Kontextmenü kann, wie über die 
Datenicons am Fensterrand, der Provenance-Baum eines einzelnen Datums 
ausgewählt werden. Auch die Detailansicht für ein Datum, mit den weiteren 
Betroffenenrechten, kann dort direkt aufgerufen werden. 


Die Navigationsleiste bietet Interaktionsmöglichkeiten, die sich nicht direkt auf 
einzelne Elemente des Informationsflusses beziehen. Sie erlaubt den letzten 
Schritt beim Eintauchen in den Graphen rückgängig zu machen oder den 
Graphen auf den Ausgangszustand zurückzusetzen. Außerdem sind in der 
Navigationsleiste Informationen zur verantwortlichen Stelle hinterlegt. Die 
Möglichkeit, im Rahmen des Rechts auf Datenübertragbarkeit, die gesamte 
Auskunft in einem maschinenlesbaren Format (JSON) zu exportieren, findet 
sich ebenfalls dort (Anforderung 53). Exportmöglichkeiten für die konkreten 
Daten finden sich bei den jeweiligen Datenkategorien im Hauptfenster. 


Die Statusleiste visualisiert die vier Unverkettbarkeitsmetriken aus Kapitel 
9. Die Unverkettbarkeit wird als prozentualer Statusbalken, farblich codiert 
von grün für 100% bis tiefrot für 0%, dargestellt (Abbildung 10.2). Uber 
einen Informationsbutton sind Erläuterungen zur Metrik zugänglich. Am Ende 
der Erläuterungen findet sich auch der Opt-Out-Button zur Deaktivierung des 
automatisierten Provenance-Trackings für alle zukünftigen Erhebungen und 
Verwendungen personenbezogener Daten durch AdBokis. So ist sichergestellt, 
dass der Betroffene beim Opt-Out eine informierte Entscheidung trifft. 


Beispiel. Alice wird bei der Abfrage ihrer Auskunft über PrivacyInsight mit 
den Werten für den Grad der Unverkettbarkeit gemäß der vier Metriken 
(Identifikationsrelation 85 %; Verknüpfungsrelation 86 %; Speicher- und Ver- 
arbeitungsrelation 94 %; Datenflussrelation 90 %) in Form einer Balkengrafik 
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10 Betroffenenautonomie zwischen Transparenz und Unverkettbarkeit 
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Abbildung 10.2: Die Auskunftsplattform Privacy Insight (links) mit integrierter Metrik für 
Unverkettbarkeit (rechts hervorgehoben) 


konfrontiert. Mit Unterstützung der hinterlegten Erläuterungen kann sie daraus 
beispielsweise ableiten, dass es eine Stelle im Unternehmen gibt, bei der sich 
allein durch die Existenz des Datenschutzauskunftssystems die Unsicherheit, 
welche personenbezogenen Daten zu ihr gehören, um 15% reduziert hat. 
AdBokis bietet ihr über das Frontend die Möglichkeit, in Zukunft auf das Da- 
tenschutzauskunftssystem zu verzichten und dafür die Gefahr der Profilbildung 
zu verringern. Aufgrund der exzellenten und umfangreichen Information in 
Privacylnsight vertraut Alice AdBokis und nimmt die zusätzliche Verkettung im 
Austausch für eine transparente Datenverarbeitung auch in Zukunft in Kauf. 


10.4 Zwischenfazit 


Im Rahmen der Betroffenenautonomie ist es zulässig, dem Betroffenen eine 
Opt-Out-Möglichkeit für die elektronische Auskunftserteilung anzubieten 
(Bestätigung von Hypothese %4). Dies gilt unter der Voraussetzung, dass der 
Betroffene anhand der Metriken für Unverkettbarkeit eine freie, informierte und 
von Erwägungen außerhalb der Datenschutzziele unabhängige Entscheidung 
treffen kann. 


Verzichtet der Betroffene auf die elektronische Auskunftserteilung, ist davon 
das Recht auf Datenübertragbarkeit mitbetroffen. Die beiden Funktionen sind 
technisch voneinander abhängig. 
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10.4 Zwischenfazit 


Die Auskunftsplattform PrivacyInsight ermöglicht dem Betroffenen die Wahr- 
nehmung der Auskunft in einem übersichtlichen, abgestuften Modell. So ist 
die Information vollständig, ohne die Aufnahmefähigkeit des Betroffenen zu 
überfordern. 


Auf der Auskunftsplattform sind die Metriken für Unverkettbarkeit, das infor- 
mierte Opt-Out, der Datenexport und die Wahrnehmung der Betroffenenrechte 
auf Berichtigung, Löschung und Sperrung an einer Stelle integriert. Wie gut 
Betroffene mit diesen vielfältigen Möglichkeiten arbeiten können, wird in 
Kapitel 12 überprüft. 
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Teil IV 


Bewertung und Ausblick 
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11 Rechtliche Bewertung des 
Datenschutzauskunftssystems 


In den Kapiteln 2 bis 4 wurden Kriterien fiir ein datenschutzgerechtes Aus- 
kunftssystem entwickelt. Auf Grundlage der daraus abgeleiteten technischen 
Anforderungen wurde in den Kapiteln 5 bis 8 ein Datenschutzauskunftssystem 
konzipiert. 


Dieses Kapitel diskutiert, inwiefern die entstandene Implementierung den 
entwickelten Kriterien des Auskunftsanspruchs gerecht wird (Abschnitt 11.1). 
Zusätzlich wird dargestellt, welche Konsequenzen die Nichteinhaltung der 
datenschutzrechtlichen Vorgaben zum Auskunftsanspruch hat (Abschnitt 11.2). 


11.1 Erfüllung der datenschutzrechtlichen 
Kriterien des Auskunftsanspruchs 


Die in Kapitel 4.3 aufgestellten datenschutzrechtlichen Kriterien wurden als 
Leitlinie für die Konzeption des in dieser Arbeit vorgestellten Datenschutzaus- 
kunftssystems verwendet. Nach erfolgter technischer Umsetzung stellt sich die 
Frage, inwiefern das Ergebnis den Kriterien entspricht. 


Nachfolgend werden die Kriterien des Auskunftsanspruchs aus Kapitel 4.3.1 
diskutiert. 


Die ersten Kriterien des Auskunftsanspruchs umreißen, auf welche Art und 
in welchem Umfang die für die Erfüllung der Auskunft erforderlichen Infor- 
mationen zu sammeln sind. In der Architekturbeschreibung des Datenschutz- 
auskunftssystems ist hinterlegt, dass PEPs in alle Applikationen integriert 
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Tabelle 11.1: Erfiillung (X) und teilweise Erfiillung (Y) der datenschutzrechtlichen Kriterien des 
Auskunftsanspruchs in Entwurf und Implementierung 


Kriterium 1 2 3 4 5 6 7 8 9 10 11 12 13 
Entwurf X X X XXXXXXX X X 
Implementierung Y Y Y X X X Y Y X X XK X 
Kriterium 14 15 16 17 18 19 20 21 22 23 24 25 26 
Entwurf X X X X X XXX XK X 
Implementierung X X X X X Y X X 
Kriterium 27 28 29 30 31 32 33 34 35 36 37 38 39 
Entwurf X X X X XK X X X X X X 
Implementierung X X X X X X X X X XK X 


werden sollen, die personenbezogene Daten verarbeiten. Wird dies umgesetzt, 
werden die Ereignisse aller Erhebungs-, Verarbeitungs-, Speicher-, Nutzungs- 
und Übermittlungsvorgänge erfasst (Kriterium 1). Das Datenschutzauskunfts- 
system sieht Techniken vor, um personenbezogene Daten so zu erfassen, dass 
eine vollständige Beauskunftung möglich ist (Kriterium 2). Im Rahmen von 
Vorarbeiten wurden Verfahren entwickelt, um E-Mails mit unstrukturierten per- 
sonenbezogenen Daten zu identifizieren! sowie strukturierte personenbezogene 
Daten in einem Webshopsystem zu erfassen.? Dadurch ist der Personenbezug 


ab dem Erhebungszeitpunkt für die Auskunft verfügbar (Kriterium 3).? 


Der Umfang der Provenance ist für die einzelnen Arten des Umgangs mit 
personenbezogenen Daten im Detail in den Kriterien festgelegt. Der Umfang 
der Provenance ergibt sich aus dem Umfang des Auskunftsanspruchs. 


Erster Aspekt des Auskunftsanspruchs sind die gespeicherten personenbe- 
zogenen Daten (Kriterium 8). Sie sind nicht Teil der Provenance, sondern 


' Bier/Prior 2014. 
? Helwig 2016. 
3 Mit Ausnahme der in Kriterium 4 vorgesehenen Fille. 
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werden in dieser referenziert. Dies ermöglicht, dass die konkreten personenbe- 
zogenen Daten erst bei Erteilung einer Auskunft auf Wunsch des Betroffenen 
aggregiert werden. Die Auskunftsplattform ist so gestaltet, dass der Betroffene 
individuell entscheiden kann, welche personenbezogenen Daten er einsehen 
möchte. Dadurch, dass die Provenance die komplette Verarbeitungskette erfasst, 
kann von jedem Informationspunkt in der Auskunftsplattform, inklusive der 
Übermittlungen, auf die gespeicherten personenbezogenen Daten zugegriffen 
werden (Kriterium 9). Um einen Schnellzugriff zu ermöglichen, werden die 
personenbezogenen Daten in der Auskunftsplattform als Icons hervorgehoben. 
Die Informationen zu Speicher- und Verarbeitungsvorgängen werden genau so 
lange gespeichert, wie die Speicherung oder Verarbeitung andauert (Kriteri- 
um 6). Diese Logik ist direkt im Datenmodell der Provenance hinterlegt. Jede 
Repräsentation im Provenance-Modell enthält in ihren Attributen Angaben zur 
Domäne, also dem Ort der Speicherung oder Verarbeitung, und zu Applikatio- 
nen und Speicherpfaden, die für die Auskunft von Relevanz sind (Kriterium 11 
und 12). Welche Applikationen und Speicherpfade Teil der Provenance sind, 
wird über Abstraktionsregeln gesteuert. Eine Sperrung personenbezogener 
Daten wirkt sich, gesteuert durch entsprechende UC-Policies, nur auf die 
Verwendung durch die verantwortliche Stelle, nicht auf die Auskunft aus 
(Kriterium 10). 


Datenverarbeitungsvorgänge und die in sie eingehenden Daten werden ebenso 
erfasst wie die Speicherung personenbezogener Daten (Kriterium 34). Der 
logische Aufbau einer Datenverarbeitung, im Falle der automatisierten Einzel- 
entscheidung, wird in der Provenance allerdings nicht erfasst (Kriterium 33). 


Für die Herkunft und externe Empfänger personenbezogener Daten sind 
spezielle Repräsentationen vorgesehen (Kriterium 13, 15, 19 und 24). In ihnen 
werden die Außenbeziehungen der verantwortlichen Stelle gespeichert, so dass 
sie dem Betroffenen als Teil der Auskunft mitgeteilt werden können. Auf der 
Auskunftsplattform sind Dritte sowie der Betroffene besonders hervorgehoben. 
Die internen Datenflüsse sind in den Kanten des Provenance-Graphen und in 
der Auskunft enthalten (Kriterium 14 und 15). Die Kanten des Provenance- 
Graphen werden auf der Auskunftsplattform dargestellt. Eine Kategorisierung 
personenbezogener Daten findet nicht statt (Kriterium 16). 
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Das Datenschutzauskunftssystem kann nur die automatisierte Datenverar- 
beitung erfassen. Insofern miissen nicht-automatisierte Weitergaben nach 
Kriterium 17 händisch zur Provenance hinzugefügt werden. Die Information, 
wann in der Vergangenheit eine Auskunft erteilt wurde, muss nicht durch das 
Datenschutzauskunftssystem erfasst werden (Kriterium 5). Es ist ausreichend, 
wenn in die Auskunftsplattform ein Zugriffsprotokoll integriert wird, auf 
das der Betroffene nach seinem Log-In zugreifen kann. Das Datenschutzaus- 
kunftssystem nutzt für den Log-In keine auskunftsspezifischen Identifikatoren, 
zeichnet aber die bei der Erhebung mitgeteilten auf (Kriterium 7). 


Jede verantwortliche Stelle ist nur für ihre eigene Datenverarbeitung verant- 
wortlich. Insofern kann Kriterium 18, die beidseitige Protokollierung einer 
Übermittlung, nur für die jeweils eigene Rolle im Übermittlungsvorgang einge- 
fordert werden. Darüber hinausgehend können sich verantwortliche Stellen nach 
Art. 26 DSGVO zu einer gemeinsamen verantwortlichen Stelle zusammen- 
schließen. Indem die Domänenhierarchie des Datenschutzauskunftssystems 
verknüpft wird, können dann auch Übermittlungsvorgänge vollständig nach- 
vollzogen werden. Solange kein gemeinsames Datenschutzauskunftssystem 
etabliert ist, ist unbekannt, wann Dritte personenbezogene Daten löschen. 
Deshalb werden Herkunfts- und Empfängerangaben im in dieser Arbeit prä- 
sentierten Datenschutzauskunftssystem gar nicht gelöscht (Kriterium 22 und 
26).! 


Bei einer Veröffentlichung personenbezogener Daten sind Informationen über 
Beginn und Ende der Veröffentlichung (Kriterium 20) durch die Repräsentation 
der Daten auf der Veröffentlichungsplattform gegeben. Der Abruf perso- 
nenbezogener Daten über eine zugangsgeschützte Plattform kann wie jede 
Übermittlung vom Datenschutzauskunftssystem erfasst werden (Kriterium 21). 


Für jeden Umgang mit personenbezogen Daten sind die jeweiligen Zwecke 
in die Auskunft mit aufzunehmen (Kriterium 27 und 29). Die Datenstruktur 
der Provenenance lässt die Aufnahme der Zwecke zu. Eine Zweckänderung 
ist in jedem Datenverwendungsschritt möglich (Kriterium 28). Vorhergehende 


! Die speziellen Zeitangaben der Kriterien 23 und 25 sind damit obsolet. 
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Zwecke sind anhand des Provenance-Graphen weiterhin riickverfolgbar. Wird 
kein neuer Zweck definiert, erbt ein Vorgang seinen Zweck vom vorherigen 
Vorgang. Da der Zweck Teil der Provenance ist, ist er unabhängig von der 
Speicherung der personenbezogenen Daten (Kriterium 30). 


Der Zeitpunkt jeder Erhebung und jedes Datenverwendungsvorgangs ist Teil der 
Provenance (Kriterium 31). Durch Abstraktionsregeln kann verhindert werden, 
dass Zeitpunkte für zu detaillierte Datenverarbeitungsvorgänge aufgezeichnet 
werden (Kriterium 32). 


Da eine Auskunft die Transparenz der Datenverarbeitung für den Betroffenen 
stärken soll, ist eine angemessene und verständliche Darstellung von großer 
Bedeutung. Die letzten Kriterien des Auskunftsanspruchs machen deshalb Vor- 
gaben für die Benutzerschnittstelle einer Auskunftsplattform. PrivacyInsight 
erfüllt alle diese Kriterien. 


PrivacyInsight ist eine Webapplikation die von jedem aktuellen Endgerät aus 
aufgerufen werden kann (Kriterium 39). Der Log-In ist nicht streng an den 
Betroffenen gebunden. Benutzername und Passwort sind nur eine Variante der 
Authentifikation und Autorisierung. Über weitere Zugriffskanäle ist deshalb 
auch ein Stellvertreterzugriff möglich (Kriterium 36). PrivacyInsight stellt den 
Betroffenen und seine Wünsche in den Mittelpunkt. Selbst nach dem Log-In 
geschieht jede Bereitstellung personenbezogener Daten nur auf Veranlassung 
des Betroffenen (Kriterium 35). Alle Interaktions- und Wahlmöglichkeiten sind 
in einer Oberfläche integriert. Für die Benutzerfreundlichkeit von PrivacyIn- 
sight wird auf Kapitel 12 verwiesen (Kriterium 38). Steht für den Betroffenen 
keine Auskunft zur Verfügung, da keine personenbezogenen Daten erhoben 
wurden, erhält er eine entsprechende Meldung (Kriterium 37). 


Das Datenschutzauskunftssystem erfüllt die rechtlichen Kriterien des 
Auskunftsanspruchs bis auf wenige Ausnahmen. Auskünfte über nicht- 
automatisierte Verarbeitungsvorgänge gemäß Kriterium 17 müssen manuell und 
einzelfallbezogen behandelt werden. Auskünfte über vorangegangene Auskünf- 
te (Kriterium 5) sind im Prototypen von PrivacyInsight noch nicht integriert, 
aber technisch trivial. Informationen zum logischen Aufbau der Verarbeitung 
bei automatisierten Einzelentscheidungen nach Kriterium 33 werden vom, 
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in dieser Arbeit vorgestellten, Datenschutzauskunftssystem nicht unterstiitzt. 
Geeignete Konzepte aus dem wissenschaftlichen Rechnen sind in der Literatur 
vorhanden.! Die Rechtsprechung legt den dahingehenden Auskunftsanspruch 
allerdings so eng aus,” dass eine Funktions-Provenance? für die Umsetzung 
desselben nicht angemessen wäre. 


11.2 Konsequenzen einer unvollständigen oder 
fehlerhaften Auskunft 


Eine effektiver Grundrechtsschutz setzt wirksame Sanktionen voraus* Erteilt 
eine verantwortliche Stelle, sei es mit oder ohne Unterstützung eines Daten- 
schutzauskunftssystems, eine unvollständige oder fehlerhafte Auskunft, dann 
handelt sie nach § 43 Abs. 1 Nr. 8a BDSG ordnungswidrig und kann nach 
§ 43 Abs. 3 S. 1 BDSG in jedem einzelnen Fall mit einer Geldbuße von bis zu 
50000 € belegt werden. Ein wirtschaftlicher Vorteil, der nach § 43 Abs. 3 S. 2 
u. 3 BDSG einen höheren Betrag rechtfertigen würde, ist bei einer fehlerhaften 
Auskunft im Regelfall nicht anzunehmen. 


Mit Einführung der DSGVO wird die mögliche Höhe einer Geldbuße deutlich 
nach oben angepasst. Die nach Art. 58 Abs. 2 Lit. i DSGVO zuständige 
Aufsichtsbehörde kann nach Art. 83 Abs. 5 Lit. b DSGVO eine Geldbuße von 
bis zu 20 Mio. Euro oder bis zu 4 % des weltweit erzielten Jahresumsatzes, je 
nachdem welcher Betrag höher liegt, verhängen. 


Damit ist allerdings noch nicht das Durchsetzungsdefizit des Datenschutzes 
behoben. Die personelle Ausstattung der Aufsichtsbehörden lässt keine Vielzahl 
von Bußgeldverfahren erwarten.” Eine Alternative könnten wettbewerbsrechtli- 
che und verbraucherrechtliche Sanktionen, insbesondere ein im Rahmen einer 


! Bose/Frew 2005; Freire et al. 2008; Moreau/Groth et al. 2008. 
? Vgl. Kapitel 3.7.6 

3 Cheney/Chiticariu/Tan 2009; vgl. Kapitel 5.1. 

4 BVerfGE 125, 260 (339). 

> Schulzki-Haddouti 2016, 114 ff. 
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Abmahnung nach $ 12 Abs. 1 S. 1 UWG vertragsstrafenbewehrt durchgesetzter 
Anspruch auf Beseitigung und Unterlassung, sein. 


Solche Sanktionen könnten zunächst nur für die Verarbeitung von Verbraucher- 
daten! durch Unternehmer? wirksam sein. Des Weiteren ist die grundsätzliche 
Abmahnbarkeit von Verstößen gegen das Datenschutzrecht auf Grundlage von 
$ 4 Nr. 11 UWG a. F.? und § 3a UWG n. F.4 in der Rechtsprechung umstritten. 
Fraglich ist, ob eine unvollständige oder fehlerhafte Auskunft eine gesetzlichen 
Vorschrift ist, die „auch dazu bestimmt ist, im Interesse der Marktteilnehmer 
das Marktverhalten zu regeln“. Marktverhalten ist jede Tätigkeit auf dem 
Markt, durch die ein Unternehmer auf Verbraucher, sonstigen Marktteilneh- 
mer oder Mitbewerber einwirkt.° Ein Verstoß gegen solch eine Vorschrift ist 
nach $ 3a UWG eine unlautere Wettbewerbshandlung, soweit der „Verstoß 
geeignet ist, die Interessen von Verbrauchern, sonstigen Marktteilnehmern oder 
Mitbewerbern spürbar zu beeinträchtigen.“ ’ 


Die ablehnende Meinung vertritt, dass die Verarbeitung personenbezogener 
Daten eines Verbrauchers durch einen Unternehmer sowie die daran anknüp- 
fenden Pflichten des Unternehmers dessen Marktauftritt nicht unmittelbar 
betreffen.* Beispielsweise gelten die Informationspflichten des § 13 Abs. 1 
TMG einem Verhalten, das dem Marktverhalten vorausgeht.? Sie könnten nur 


! Verbraucherbegriff des $ 13 BGB. 

2 Definiert in $ 14 BGB. 

3 Unlauter handelt insbesondere, wer ,,1 1. einer gesetzlichen Vorschrift zuwiderhandelt, die auch 
dazu bestimmt ist, im Interesse der Marktteilnehmer das Marktverhalten zu regeln.“ 

4 Vorschrift neugefasst durch das zweite Gesetz zur Änderung des Gesetzes gegen den unlauteren 
Wettbewerb vom 02.12.2015 (BGBl. 12015 Nr. 49 S. 2158), in Kraft getreten am 10.12.2015, 
http://dipbt.bundestag.de/extrakt/ba/WP18/647/64799.html. in Klarstellung der Umsetzung der 
Richtlinie 2005/29/EG. 

5 Gleichlautend in $ 4 Nr. 11 UWG a. F. und $ 3a UWG n. F. 

6 KG Berlin, MMR 2011, 464 (465). 

7 Das Prinzip der Spürbarkeit war schon zuvor im UWG enthalten und wird nun explizit an dieser 
Stelle erwähnt. — Insofern ändert sich nichts ggü. $ 4 Nr. 11 UWG a. F. 

8 KG Berlin, MMR 2011, 464 (465). 

9 KG Berlin, a. a. O. 
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als Marktverhaltensvorschrift angesehen werden, wenn ihnen eine sekundä- 
re Schutzfunktion im Hinblick auf die Wettbewerber innewohnen wiirde.! 
Der Gesetzgeber habe jedoch bei der Gesetzgebung keinen überindividuellen 
wettbewerblichen Schutzgedanken verfolgt. Der freie Wettbewerb sei in der Be- 
gründung zur Vorschrift? nur im Sinne einer Rechtfertigung der Einschränkung 
von Persönlichkeitsrechten der Nutzer berücksichtigt worden. Da sich daten- 
schutzbezogene im Gegensatz zu geschäftsbezogenen Informationspflichten 
nicht auf das kommerzielle Verhalten eines Verbrauchers auswirken, seien auch 
die Verbraucherinteressen nicht spürbar beeinträchtigt.* Der gleiche Schluss 
würde sich für Auskunftspflichten aufdrängen. 


Die zustimmende Meinung sieht marktbezogene Datenschutzregeln als Markt- 
verhaltensregeln für Unternehmer. Sie bezieht sich dabei auf die Begründung 
der DSRL. Die DSRL soll danach den grenzüberschreitenden Verkehr perso- 
nenbezogener Daten auch im Hinblick auf einen fairen Wettbewerb regeln.° Die 
Vorschriften dienen demgemäß nicht nur dem Schutz der Persönlichkeitsrechte 
der Betroffenen, sondern auch dem Schutz der Interessen der Mitbewerber 
an gleichen Wettbewerbsbedingungen.® Aufklärungspflichten tragen außer- 
dem zum Schutz der Verbraucherinteressen bei der Marktteilnahme bei und 
beeinflussen die Entscheidungen und das kommerzielle Verhalten der Verbrau- 
cher.’ Eine Vorschrift zum Schutz anderer Rechtsgüter eines Verbrauchers 
ist eine Marktverhaltensvorschrift, wenn das geschützte Interesse durch die 
Marktteilnahme berührt wird.* Dem ist zu folgen. Die zunehmende wirtschaft- 
liche Bedeutung der Erhebung und Verarbeitung personenbezogener Daten 


KG Berlin, a. a. O. 

BT-Drs. 13/7385, S. 21 zum TDDSG. 

3 KG Berlin, a. a. O. 

4 LG Frankfurt, BeckRS 2014, 22875; ebenso OLG München, MMR 2012, 317. 

5 U.a. ErwGr 7 und 8. 

6 OLG Hamburg, K&R 2013, 601. 

7 OLG Hamburg, a.a. O. und ebenso LG Köln, Beschluss vom 26.11.2015, Az. 33 O 230/15; 
LG Hamburg, Beschluss vom 07.01.2016, Az. 315 O 550/15; LG Hamburg, Beschluss vom 
13.03.2016 Az. 312 O 127/16. 

8 OLG Karlsruhe, NJW 2012, 3312 (3314). 
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beeinflusst das Verständnis des Datenschutzrechts als Marktverhaltensregel in 
positivem Sinne. ! 


Allerdings ist der Auskunftsanspruch, im Gegensatz zu den Informations- 
pflichten, zumindest der Verbraucherentscheidung zum Aufbau einer Kun- 
denbeziehung nicht vorgelagert. Eine Auskunft soll ferner, im Gegensatz zu 
beispielsweise einem Werbeschreiben,” nicht unmittelbar das Verhalten des 
Verbrauchers im Markt beeinflussen. Der Unternehmer erteilt die Auskunft 
nicht initiativ, um sich einen wettbewerbsrechtlichen Vorteil zu verschaffen, 
sondern responsiv, in Reaktion auf die Anfrage des Verbrauchers. Allenfalls 
in den Fällen, in denen der Unternehmer den Umgang mit personenbezo- 
genen Daten aus Imagegründen systematisch fehlerhaft darstellt, kann von 
einer mittelbaren marktbezogenen Beeinflussung des Verbraucherverhaltens 
ausgegangen werden. 


Augenscheinlich eindeutiger stellt sich die Situation im Hinblick auf das UKlaG 
dar. Mit dem Gesetz zur Verbesserung der zivilrechtlichen Durchsetzung von 
verbraucherschützenden Vorschriften des Datenschutzrechts vom 17.02.2016° 
wurden die Vorschriften des BDSG in den Kanon der Verbraucherschutzge- 
setze aufgenommen,* die die Zulässigkeit der Erhebung, Verarbeitung oder 
Nutzung personenbezogener Daten eines Verbrauchers durch einen Unterneh- 
mer regeln. Bei einer Zuwiderhandlung gegen diese Vorschriften kann ein 
Unternehmer nach $ 2 Abs. 1 UKlaG auf Unterlassung und Beseitigung in 
Anspruch genommen werden. Beseitigung meint die Maßnahmen gemäß der 
datenschutzrechtlichen Vorschriften auf Löschung, Sperrung und Berichtigung 
wie in § 35 BDSG zu finden. ° 


Fraglich ist, ob der Auskunftsanspruch eine Regelung ist, die in den An- 
wendungsbereich des UKlaG fällt. Nach der Gesetzesbegründung werden 
alle datenschutzrechtlichen Vorschriften erfasst, „die Unternehmer für eine 
zulässige Erhebung, Verarbeitung oder Nutzung von Verbraucherdaten [...] 


' LG Düsseldorf, MMR 2016, 328 (330). 

2 OLG Stuttgart, MMR 2007, 437. 

3 BGBI. I 2016 Nr. 8 S. 233, http://dipbt.bundestag.de/extrakt/ba/WP 18/65 1/65144.html. 
4 Genauer: In § 2 Abs. 2 S. 1 Nr. 11 UKlaG. 

5 BT-Drs. 18/6916, 8. 
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beachten müssen.“! Eine Erhebung, Verarbeitung und Nutzung personenbezo- 
gener Daten ist nach der Maßgabe von $ 4 Abs. 1 BDSG zulässig. Sie wird 
nicht dadurch unzulässig, dass eine Auskunft nach $ 34 BDSG fehlerhaft oder 
unvollständig ist. Die Auskunft ist nicht kausal für die Datenpreisgabe.” $ 34 
BDSG ist eine Vorschrift, die Unternehmer bei der zulässigen Verarbeitung 
von Verbraucherdaten beachten müssen. Somit ist im Hinblick auf $ 34 BDSG 
kein Unterlassungsanspruch gegen den Rechtsverstoß einer unvollständigen 
Auskunft gegeben. 


Ungeachtet all dessen eignet sich die Vollständigkeit und Korrektheit der 
Auskunft kaum für eine Abmahnung. Erstens fallen die Anspruchsberechtigten 
der Auskunft (Betroffene), die die Vollständigkeit und Korrektheit überprü- 
fen könnten, und die Anspruchsberechtigten der Unterlassung? auseinander. 
Zweitens ist eine Auskunft individuell und geht nicht einer Vielzahl von Ver- 
brauchern in gleichartiger oder zumindest vergleichbarer Weise zu, wie dies 
beispielsweise für Allgemeine Geschäftsbedingungen (AGB) der Fall ist. Es ist 
somit nur schwer möglich, eine Unterlassungsaufforderung mit hinreichender 
Präzision zu formulieren. 


11.3 Zwischenfazit 


Das in dieser Arbeit vorgestellte Datenschutzauskunftssystem erfüllt alle 
rechtlichen Kriterien des Auskunftsanspruchs und damit das Konstruktionsziel 
K6. Der Einsatz eines Datenschutzauskunftssystems ist unumgänglich, um eine 
Auskunft in modernen, vernetzten IT-Systemen in vollem Umfang erteilen zu 
können. Durch die Wahlmöglichkeit des Betroffenen zwischen Unverkettbarkeit 
und Transparenz, anhand einer in die Auskunftsplattform integrierten Metrik, 
ist der Einsatz eines Datenschutzauskunftssystems verhältnismäßig. 


' BT-Drs. 18/4631, 23. 

2 Im Gegensatz zu den Hinweisen gemäß § 4a Abs. 1 S. 1 BDSG. 

3 Nach § 3 Abs. 1 S. 1 UKlaG Verbraucherverbände, Verbände zur Förderung gewerblicher oder 
selbständiger beruflicher Interessen, Industrie- und Handelskammern und die Handwerkskam- 
mern. 
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Ob in Zukunft ein Handlungsdruck auf verantwortliche Stellen entsteht, Aus- 
kunftsansprüche vollumfänglich zu befriedigen, hängt von der Durchsetzung 
des Anspruchs ab. Die Aufsichtsbehörden bekommen mit der DSGVO stärkere 
Sanktionsmöglichkeiten in die Hand. Ihre personelle Ausstattung und ihr 
Selbstbild als kooperative Institution ändert sich dadurch nicht. 


Durch Wettbewerbs- und Verbraucherrecht ist keine Verbesserung der Be- 
troffenenrechte zu erwarten. Der Auskunftsanspruch ist keine Voraussetzung 
für eine zulässige Erhebung, Verarbeitung oder Nutzung personenbezogener 
Daten. Demnach können Unternehmen weder nach UWG noch nach UKlaG 
abgemahnt werden. 
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Unabhängig von seiner technischen und rechtlichen Güte ist das Datenschutz- 
auskunftssystem nur dann sinnvoll, wenn es von den potentiellen Nutzern des 
Systems, den Betroffenen der Datenverarbeitung, erfolgreich eingesetzt werden 
kann. Deshalb wurde die Auskunftsplattform des Datenschutzauskunftssys- 
tems, PrivacyInsight,! in einer Nutzerstudie auf ihre Gebrauchstauglichkeit 
hin überprüft.” 


Abschnitt 12.1 stellt den Aufbau und Ablauf der Studie und die Zusammen- 
setzung der für die Studie ausgewählten Probanden vor. Der Vergleich von 
PrivacyInsight mit bestehenden Ansätzen zur Auskunft wird in Abschnitt 12.2 
vorgestellt. Die Ergebnisse der Evaluation des erweiterten Funktionsumfangs 
von PrivacyInsight findet sich in Abschnitt 12.3. Ergänzend wurden in der 
Studie auch Aspekte der Unverkettbarkeitsmetrik aus Kapitel 9 und 10 abge- 
fragt. Die Einschätzung der Probanden wird in Abschnitt 12.4 wiedergegeben. 
Den Abschluss in Abschnitt 12.5 bildet die Analyse allgemeiner Fragen zur 
Erwartungshaltung der Betroffenen. 


12.1 Struktur der Studie 


Mit der vorliegenden Nutzerstudie wurden drei Ziele verfolgt. Erstens sollte 
überprüft werden, ob Informationen über die Verarbeitung personenbezogener 
Daten mit PrivacyInsight genauso effizient und effektiv gefunden werden 


! Zum Funktionsumfang, siehe Kapitel 10.3 
2 Die Studie wurde bereits in Bier/Kühne/Beyerer 2016 veröffentlicht. 
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Abbildung 12.1: Auskunftsverfahren im Vergleich 


können, wie bei bestehenden Auskunftsverfahren. Probanden wurden dazu 
Aufgaben gestellt. Die Quote ihrer erfolgreichen Lösungen sowie ihr Zeitbedarf 
wurden gemessen. Zweitens sollte evaluiert werden, wie die Gebrauchstaug- 
lichkeit von PrivacyInsight, auch im Vergleich mit den bereits bestehenden 
Verfahren, durch Anwender empfunden wird. Mit Hilfe zweier etablierter 
Usability-Fragebögen wurde deshalb die subjektive Einschätzung der Proban- 
den abgefragt. Drittens war die Frage zu beantworten, ob die zusätzlichen 
Funktionen von PrivacyInsight, insbesondere die Metrik für Unverkettbarkeit, 
von den Anwendern als nutzbringend empfunden werden. Dafür wurde ein 
zusätzlicher, auf die Studie abgestimmter Fragebogen hinzugezogen. 


Als Vergleichsmaßstab für die ersten beiden Ziele der Studie wurden zwei 
Auskunftsverfahren gewählt: (1) Ein JSON-Dokument (Abbildung 12.1c), 
welches den Stand der Praxis für Datenschutzauskünfte repräsentiert! und 
(2) GenomSynlig (Abbildung 12.1b), die Auskunftsplattform von A4Cloud 
und das derzeit beste, in der Forschung verfügbare Privacy-Dashboard. Von 
GenomSynlig wurde die mit PrivacyInsight vergleichbare Ansicht „Trace View“ 
herangezogen.” 


1 Beispielsweise als Downloadformat im Google Dashboard, https://www.google.com/dashboard, 
abgerufen am 9. Mai 2017; ähnlich komplex sind auch die Facebook-Datenbestände, http: 
//www.europe- v-facebook.org/DE/Datenbestand/datenbestand.html, abgerufen am 9. Mai 2017; 
die papierenen Auskiinfte deutscher Unternehmen (siehe Kapitel 1.1.1) sind meist tabellarisch 
strukturiert, aber keineswegs deutlich übersichtlicher. 

2 http://hei.cse.kau.se:8000/Datatrack_views/datatrack-traceview.html, eine kurze Einführung 
zum allgemeinen Funktionsumfang findet sich in Kapitel 1.1.2. 
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Das JSON-Dokument besteht aus 45 Seiten im PDF-Format. Am Anfang des 
Dokuments befindet sich ein Abschnitt mit der Firma und einer postalischen 
Kontaktadresse der verantwortlichen Stelle. Auf den tibrigen Seiten werden die 
personenbezogenen Daten sowie die verarbeitenden und empfangenden Stellen 
aufgelistet. Die Struktur entspricht der Datenstruktur in Kapitel 6.4. 


GenomSynlig bietet die Möglichkeit unterschiedliche Filter zu setzen. In 
der Evaluation wurde es so konfiguriert, dass nur ein Unternehmen, die 
AdBokis GmbH, angezeigt wurde. Dadurch wurde die Übersichtlichkeit für 
die Aufgabenstellung erhöht. 


12.1.1 Stichprobe 


An der fünftägigen Studie im Frühjahr 20 16 nahmen insgesamt 31 Personen teil. 
Die Probanden wurden aus dem Umfeld der Karlsruher Forschungslandschaft 
rekrutiert. Deshalb hatten 74 % der Probanden einen akademischen Abschluss. 
Alle Probanden hatten zumindest das Abitur, die Fachhochschulreife oder einen 
Abschluss der erweiterten Oberschule. 32 % der Teilnehmer waren Studenten, 
65 % waren erwerbstätig. Da Studenten bereits einen Bachelorabschluss haben 
können, sind sie nicht äquivalent mit den Probanden ohne akademischen 
Abschluss. 


39% der Teilnehmer waren weiblich, 61 % männlich. 65 % der Teilnehmer 
kamen aus einer Großstadt oder ihrem Einzugsbereich. Die übrigen Teilnehmer 
verteilten sich relativ gleichmäßig auf Städte, Kleinstädte und den ländlichen 
Bereich. 


Die Teilnehmer besaßen ausgeprägtes technisches Hintergrundwissen. 68 % der 
Teilnehmer können technische Probleme fast immer selbst lösen, 19 % zumin- 
dest manchmal. 29 % der Teilnehmer haben bereits selbst eine Webanwendung 
entwickelt. Allerdings hatten nur 19 % der Teilnehmer in der Vergangenheit 
bereits selbst ein oder mehrmals ein Auskunftsgesuch nach $ 34 BDSG gestellt. 


Im Vergleich zur Gesamtbevölkerung ist die Stichprobe überdurchschnittlich 
gebildet und technisch affın. Außerdem ist die Quote männlicher Teilnehmer 
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Abbildung 12.2: Altersverteilung der Stichprobe 


höher als die weiblicher Teilnehmer. Auch die Altersverteilung ist nicht reprä- 
sentativ. Der Anteil der Internetnutzer an der deutschen Gesamtbevölkerung, 
die 45 Jahre oder älter sind, liegt bei ca. 46 %! während der Anteil der über 
45 jährigen in der Stichprobe bei höchstens 29 % (9 Personen, Abbildung 12.2) 
liegt. 


Auf der anderen Seite entspricht die Gesamtbevölkerung auch nicht den ersten 
Nutzern einer neuen Datenschutztechnologie. Erstnutzer für Datenschutztech- 
nologien sind überwiegend männlich, jung und gebildet.” Insofern sind die 
Ergebnisse der Studie mit der gewählten Stichprobe ein guter Indikator für 
die zukünftige Akzeptanz einer Auskunftsplattform. Die Gebrauchstauglich- 
keit wird anhand einer Personengruppe bestimmt, die das System tatsächlich 
verwenden würde. 


1 Statistisches Bundesamt 2015, 206. 
? Spiekermann 2005. 
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12.1.2 Versuchsaufbau und Ablauf 


Die Nutzerstudie fand unter Laborbedingungen statt. Jeder Teilnehmer be- 
arbeitete die Aufgaben und Fragebögen alleine und unter Beobachtung des 
Studienleiters. Im Labor wurden zwei getrennte Arbeitsplätze genutzt.! Am 
einen Arbeitsplatz wurden die gestellten Aufgaben mit den drei elektronischen 
Auskunftvarianten bearbeitet, am anderen Arbeitsplatz wurden die schriftlichen 
Fragebögen ausgefüllt. Diese Konfiguration erlaubte eine Vorbereitung der 
Aufgaben während der Bearbeitung der Fragebögen durch den Probanden. 


Nach einer organisatorischen Einführung wurde den Probanden das Szena- 
rio erläutert. Es entsprach im Großen und Ganzen dem Minimalbeispiel aus 
Kapitel 1.6. Für GenomSynlig wurden leichte Anpassungen an den Rollen vor- 
genommen. Der Kunde hieß bei Tests mit diesem System, dem voreingestellten 
Namen im online verfügbaren Prototypen entsprechend, Bob Bobsson. Die 
genaue Szenariobeschreibung findet sich im Anhang G.1. 


Der Versuch bestand organisatorisch aus zwei Aufgabenteilen. Zwischen und 
nach diesen Teilen waren die Fragebögen auszufüllen. 


Im ersten Teil wurden die drei Auskunftsverfahren PrivacyInsight, GenomSynlig 
und JSON miteinander verglichen. Um einen Einfluss der Reihenfolge der 
Systeme auf die Ergebnisse auszuschließen, wurden die Auskunftsverfahren 
in allen 6 möglichen Permutationen getestet. Jedem Probanden wurde eine 
Permutation zugewiesen. So wurde jede Permutation mindestens 5 Mal getestet. 
Zumindest im ersten Teil war den Probanden dadurch nicht klar, welches System 
das im Rahmen dieser Arbeit entwickelte war. 


Den Probanden wurden für jedes System 5 Aufgaben gestellt,” die innerhalb 
von maximal 2 Minuten zu bearbeiten waren. Die Bearbeitungszeit und 
der Lösungserfolg wurden protokolliert. Wurde die Aufgabe nicht innerhalb 
von 2 Minuten abgearbeitet, galt sie als nicht gelöst. Nach dem Ende der 
Bearbeitung aller Aufgaben hatte der Proband jeweils noch eine Minute Zeit 


l Blickmesslabor des Fraunhofer IOSB in Karlsruhe. 
? Siehe Abbildung G.3 im Anhang. 
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sich mit dem System vertraut zu machen. AnschlieBend wurde er angewiesen, 
einen Usability-Fragebogen auszufüllen. 


Im zweiten Teil wurden die besonderen Funktionen von PrivacyInsight getestet. 
Der zweite Teil begann mit einer Einführung in die Funktionen und die 
Benutzung von PrivacyInsight durch den Studienleiter. Anschließend hatte 
der Proband 10 Aufgaben zu bearbeiten,' die über den Funktionsumfang 
von GenomSynlig und JSON hinausgehen. Dem Probanden wurden dadurch 
die Möglichkeiten von PrivacyInsight demonstriert. Für jede Aufgabe waren 
wieder 2 Minuten vorgesehen. Die Ergebnisse wurden protokolliert. Nach 
Bearbeitung aller Aufgaben hatte der Proband nochmals 2 Minuten Zeit, um 
sich mit PrivacyInsight vertraut zu machen. Anschließend waren zwei weitere 
Usability-Fragebögen auszufüllen. 


Ein Usability-Fragebogen war der kompakte System Usability Scale (SUS). 
Der aus 10 Items bestehende SUS ist eine technologieunabhängige Likert-Skala. 
Das Antwortformat ist auf 5 Stufen von 1 bis 5 festgelegt. Die daraus berechnete 
Skala kann Werte zwischen 0 und 100 annehmen. Diese Werte lassen sich in ein 
Bewertungssystem von „schlechtestmöglich“ bis „bestmöglich“ übersetzten.? 
Während der SUS ursprünglich eindimensional war, stellten Lewis und Sauro 
fest, dass „Erlernbarkeit“ als zweiter Faktor abgeleitet werden kann.* Der SUS 
wurde im ersten Teil dazu verwendet, um die subjektive Gebrauchstauglichkeit 
der drei Systeme zur Auskunftserteilung miteinander zu vergleichen. Der SUS 
im zweiten Teil sollte, im Vergleich mit den Ergebnissen aus dem ersten Teil, 
zeigen, wie sich die Wahrnehmung der Nutzer durch die verbesserte Kenntnis 
von PrivacyInsight verändert hat. 


Der in der Literatur vorgestellte PET-USES-Fragebogen? wurde nicht verwen- 
det, da viele Fragen von PET-USES nicht zu Auskunftsplattformen passen. Der 
erste Teil von PET-USES hat eine hohe Übereinstimmung mit dem SUS. 


! Siehe Abbildungen G.5 und G.6 im Anhang. 
? Brooke 1996. 

3 Bangor/Kortum/Miller 2009. 

4 Lewis/Sauro 2009. 

5 Wästlund/Wolkerstorfer/Köffel 2010. 
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Der zweite, im zweiten Teil verwendete, Fragebogen war der umfangreichere 
User Experience Questionnaire (UEO).' Der UEQ besteht aus 26 Items mit 
einem 7-stufigen Antwortformat semantischer Differentiale.” Mit dem UEQ 
wird der subjektive Eindruck eines getesteten Systems auf einen Probanden 
abgefragt.” Die 6 Skalen des UEQ sind Attraktivität, Effizienz, Durchschaubar- 
keit, Steuerbarkeit, Stimulation und Originalität. Anhand dieser Skalen wurde 
die Nutzerrezeption von PrivacyInsight genauer analysiert. 


Zum Abschluss der Studie wurden jedem Teilnehmer noch ein demographischer 
und ein ergänzender Fragebogen vorgelegt. Auf die demographischen Angaben 
wurde im vorhergehenden Abschnitt eingegangen. Die Antworten auf die 
ergänzenden Fragen werden in den Abschnitten 12.4 und 12.5 besprochen. 


Der genaue Ablauf eines Probandendurchlaufs findet sich in Anhang G.1. Die 
gestellten Aufgaben finden sich im Anhang G.2, die verwendeten Fragebögen 
im Anhang G.3. 


12.2 Vergleich von PrivacyInsight mit 
alternativen Auskunftsverfahren 


Im ersten Teil der Studie haben die 5 gestellten Aufgaben folgende Szenarien 
und Fragestellungen abgedeckt: (1) Wurde ein personenbezogenes Datum 
einer bestimmten Kategorie von der verantwortlichen Stelle erhoben? (2) Wel- 
ches personenbezogene Datum wird gespeichert (konkreter Inhalt)? (3) Ist 
es erkenntlich, wenn mehrere Daten einer Kategorie gespeichert wurden? 
(4) Wie kann der Betroffene die Löschung eines personenbezogenen Datums 
beantragen? (5) Wie kann der Fluss eines personenbezogenen Datums vom 
Betroffenen zur verantwortlichen Stelle dargestellt werden? Alle Aufgaben sind 
mit allen drei Auskunftssystemen, zumindest auf Umwegen, lösbar. 


! Laugwitz/Held/Schrepp 2008. 

2 Semantische Differentiale sind begrifflich entgegengesetzte Eigenschaftspaare wie „schnell - 
langsam“. 

3 Rauschenberger/Thomaschewski/Schrepp 2013. 
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Aufgabenbewältigung Die erste Aufgabe wurde nur von 35 % der Probanden 
mit GenomSynlig richtig gelöst, wobei 7 Teilnehmer am Ablauf der Zeit 
scheiterten. Mit PrivacyInsight waren bereits 71 % der Probanden in der Lage 
die Aufgabe zu lösen, mit JSON waren es sogar 90 %. Für den Zeitbedarf ergab 
sich die gleiche Reihung (vgl. Tabelle 12.1). 


Tabelle 12.1: Mittlerer Zeitbedarf zur Aufgabenbearbeitung in Sekunden (Maximum: 120 s) im 
ersten Teil 


Aufgabe 1 2 3 4 5 


Privacylnsight 51,29 38,65 55,45 24,97 65,52 
GenomSynlig 60,13 42,74 57,61 74,52 70,71 
JSON 38,84 23,90 52,32 50,29 85,23 


In der zweiten Aufgabe schnitt GenomSynlig mit einer Erfolgsquote von 48 % 
mit Abstand am schlechtesten ab. PrivacyInsight und JSON waren mit einer 
Erfolgsquote von 90 % bzw. 94 % fast gleich auf. Diejenigen Probanden, die 
mit PrivacyInsight innerhalb der vorgegebenen Zeit mit der Bearbeitung der 
Aufgabe fertig wurden, lösten die Aufgabe alle richtig. Die Antworten bei 
GenomSynlig kamen zwar fast genauso schnell, waren aber häufig falsch. Die 
Probanden wurden von der Darstellung in die Irre geführt. Personenbezogene 
Daten konnten nicht klar einer verantwortlichen Stelle zugeordnet werden. 


Die dritte Aufgabe wurde für alle Systeme ähnlich schnell bearbeitet, allerdings 
mit stark unterschiedlicher Qualität der Ergebnisse. 68 % der Probanden fanden 
mit PrivacyInsight die richtige Lösung während es mit GenomSynlig und JSON 
nur 52% bzw. 39% waren. Ähnlich wie bei der zweiten Aufgabe war die 
Zuordnung personenbezogener Daten in PrivacyInsight besser erkennbar. 


Die vierte Aufgabe zielte auf die Integration der Auskunft und der weiteren 
Betroffenenrechte ab. Diese ist mit PrivacyInsight deutlich am besten gelöst. 
Nur ein Proband war nicht in der Lage, die Aufgabe erfolgreich zu bearbeiten. Er 
scheiterte am vorgegebenen zeitlichen Rahmen. Alle anderen Probanden fanden 
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in kurzer Zeit den richtigen Button. Ganz anders bei GenomSynlig und JSON. 
Bei diesen Ansätzen lag die Erfolgsquote nur bei 45 % bzw. 64 %. GenomSynlig 
bietet zwar auch einen Löschbutton, dieser ist jedoch sehr versteckt platziert. 
Bei JSON mussten die Probanden auf die Idee kommen, eine postalische 
Anfrage zu stellen. 


Die letzte Aufgabe wandte sich den Datenflüssen zu. Bei JSON sind diese 
anhand der Datenkennungen manuell nachvollziehbar. Die letzte war mit 
Abstand die schwierigste Aufgabe. Mit PrivacyInsight waren immerhin 58 % 
der Probanden in der Lage, einen Datenfluss hervorzuheben. Mit GenomSynlig 
und JSON waren es nur 35 % bzw. 16 %. 


Mit GenomSynlig hatten die Probanden über die ersten vier Aufgaben hinweg 
den größten Zeitbedarf. Bei der letzten Aufgabe stand JSON etwas schlechter 
da, da eine nicht-interaktive Darstellung für das Aufzeigen eines Datenflusses 
nicht geeignet ist. Bei den ersten drei Aufgaben war JSON am schnellsten zu 
verwenden, bei den anderen beiden war PrivacyInsight die am schnellsten 
zu bedienende Oberfläche. Der Zeitvorteil von JSON lag darin begründet, 
dass es bei den ersten Aufgaben möglich war, die Textsuche im PDF zu 
verwenden. Lösungsquote und Geschwindigkeit zusammengenommen brachte 
PrivacyInsight für die Probanden die besten Ergebnisse. 


Fragebögen Die Ergebnisse des SUS sind in Abbildung 12.3 zusammenge- 
fasst. Alle drei Systeme lagen nicht im oberen Bereich der Skala. Dabei ist zu 
berücksichtigen, dass die Gebrauchstauglichkeit in einer Testsituation unter 
Stress erfahren wurde. Außerdem handelt es sich bei Auskunftsplattformen um 
eine völlig neue Anwendungsgattung. 


Trotz seiner ordentlichen Performance in den ersten drei Aufgaben wurde 
JSON im Median nur mit 27,5 Punkten bewertet. GenomSynlig erreichte einen 
Median von 45 Punkten. Auf der SUS-Skala steht dies für eine eine geringe 
bis mittelmäßige Gebrauchstauglichkeit. PrivacyInsight lag im Median bei 
67,5 Punkten. Dies ist eine mittlere bis gute, aber weder eine exzellente noch 
eine bestmögliche Bewertung. Die Erlernbarkeit lag bei PrivacyInsight und 
GenomSynlig in etwa auf dem gleichen Niveau wie die Gesamtbewertung. 
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Abbildung 12.3: SUS-Score der drei Vergleichsverfahren 


Die Streuung der Bewertungen war bei allen drei Verfahren groß. Die Permu- 
tation der Reihenfolge der Verfahren hatte keinen signifikanten Einfluss auf 
die Bewertungen. Gemeinsam mit der Aufgabenbewältigung kann dennoch 
PrivacyInsight als das klar überlegene System identifiziert werden. 


12.3 Nutzerrezeption des erweiterten 
Funktionsumfangs von PrivacyInsight 


Im zweiten Teil wurden die Probanden ausschließlich mit PrivacyInsight 
konfrontiert. Die 10 Aufgaben drehten sich rund um den Funktionsumfang 
von Privacylnsight, der über GenomSynlig und eine herkömmliche, textuelle 
Auskunft hinausgeht. 


Die ersten beiden Aufgaben befassen sich mit der Übermittlung personenbezo- 
gener Daten. Die dritte Aufgabe fragt nach dem Zweck der Speicherung. Die 
Aufgaben 4 und 6 nehmen den gesamten Datenfluss in den Blick. Die fünfte 
Aufgabe setzt sich mit der Kategorie der gespeicherten Daten auseinander. 
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Die letzten vier Aufgaben umfassen den Datenexport und -download, einen 
Antrag auf Berichtigung und abschließend das Zurücksetzen der Darstellung. 
Der genaue Aufgabentext findet sich in Anhang G.2. 


Aufgabenbewältigung Die Erfolgsquote war über alle Aufgaben hinweg sehr 
hoch (Tabelle 12.2). Die letzten vier Aufgaben konnten von über 90 % der 
Probanden gelöst werden. Der Zeitaufwand lag im Mittel bei weniger als 25 s 
und war damit weitaus niedriger als bei den Aufgaben im ersten Teil. Aufgrund 
der vorherigen Einweisung konnten alle Probanden die letzte Aufgabe in unter 
20 Sekunden lösen. 


Einzig Aufgabe 4 konnte von weniger als der Hälfte der Probanden gelöst 
werden. Nur 32 % der Probanden waren in der Lage, zu identifizieren, durch 
wie viele Abteilungen ein personenbezogenes Datum floss. Zu erkennen, wann 
die Hierarchieebene der Abteilungen in der Informationsflussvisualisierung 
geöffnet war, war schwer. 


Es war allerdings nicht so, dass die Probanden das Expandieren von Knoten 
und das Hineinnavigieren in tiefere Ebenen grundsätzlich nicht verstanden 
hätten. Die Mehrzahl der Probanden war nach den in der Studie gemach- 
ten Beobachtungen in der Lage, Knoten zu öffnen und Untereinheiten zu 
identifizieren. 


Tabelle 12.2: Erfolgsquote und mittlerer Zeitbedarf zur Aufgabenbearbeitung im zweiten Teil (nur 
PrivacyInsight) 
Aufgabe 1 2 3 4 5 


Erfolgsquote 70,97% 61,29% 83,87% 32,26% 80,65% 
Mittlerer Zeitbedarf 44,90 s 72,09 s 40,70s 54,81s 45,13s 


Aufgabe 6 7 8 9 10 


Erfolgsquote 83,87% 9,55% 93,55% 93,55% 100,00 % 
Mittlerer Zeitbedarf 43,45 s 17,03 s 16,57 s 22,06 s 3,06s 
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Abbildung 12.4: SUS-Score von PrivacyInsight im ersten und zweiten Teil 


Fragebögen Der wesentliche Unterschied zwischen den SUS-Ergebnissen 
von PrivacyInsight im ersten und im zweiten Teil ist eine starke Reduktion 
der Streuung (vgl. Abbildung 12.4). Der Interquartilsabstand beträgt nur 
noch 30 Punkte (zuvor: 37,5 Punkte). Nur noch ein Proband bewertet die 
Gebrauchstauglichkeit von PrivacyInsight mit weniger als 27,5 Punkten (zuvor: 
4 Probanden). Der Median bleibt dabei fast unverändert und steigt nur leicht auf 
70 Punkte. Die Probanden sind sich also nach wiederholter Verwendung von 
PrivacyInsight einiger über dessen Bewertung. Wissen hat eine konsolidierende 
Wirkung. 


Aus dem UEQ werden für alle Skalen Werte im Bereich von -3 bis +3 berech- 
net. Gemäß dem Auswerteschema werden Werte von -3 bis -0,8 als negativ, 
Werte von -0,8 bis +0,8 als neutral und Werte zwischen +0,8 und +3 als 
positiv angesehen. Probanden vermeiden normalerweise extreme Bewertungen, 
weshalb sich der Wertebereich realstischer meist zwischen -2 und +2 bewegt. 
Mit den Auswertetools des UEQ werden Vergleichswerte etablierter Syste- 
me mitgeliefert. Da PrivacyInsight kein Produktivsystem ist, ist ein direkter 
Vergleich mit diesem Datensatz mit Vorsicht zu interpretieren. 
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PrivacyInsight erreichte im Mittel einen Attraktivitätswert von 1,25 — ein 
überdurchschnittlicher Wert. Die Effizienz erreichte einen durchschnittlichen 
Wert von 1,27. 


Die Durchschaubarkeit wurde mit Abstand am schlechtesten bewertet. Sie 
erreichte nur einen mittleren Wert von 0,49. Damit befindet sie sich zwar noch 
im neutralen Bereich, jedoch unter den schlechtesten 25 % der Systeme im 
Hinblick auf den Vergleichsdatensatz. PrivacyInsight wird von den Probanden 
als verwirrend und kompliziert wahrgenommen. Da die Darstellungsform für 
alle Probanden neu war, ist dies nicht verwunderlich. 


Der Durchschaubarkeit folgt die Steuerbarkeit. Sie wird mit einem mittleren 
Wert von 0,87 als durchschnittlich angesehen. 


Demgegenüber geben Stimulation und Originalität einen positiven Ausblick. 
Sie schneiden mit mittleren Werten von 1,26 und 1,5 überdurchschnittlich gut 
ab. PrivacyInsight wird als originell und neuartig beschrieben. 


Die Permutation der Reihenfolge der Systeme im ersten Teil hat keinen 
messbaren Einfluss auf die Bewertungen im zweiten Teil. 


Den Probanden wurden noch zusätzliche Fragen gestellt, um ihre Einschätzung 
des Nutzens von PrivacyInsight abzufragen. Da diese Fragen am Ende gestellt 
wurden und den meisten Probanden klar gewesen sein dürfte, dass Privacy- 
Insight die getestete Neuentwicklung ist, ist damit zu rechnen, dass sie nicht 
unvoreingenommen beantwortet wurden. 


Dennoch ist erfreulich, dass, bis auf eine Person, alle Probanden für die zu- 
sätzlich in PrivacyInsight verfügbaren Informationen eine höhere Komplexität 
hingenommen haben. Die Integration der Datenschutzauskunft mit den übrigen 
Betroffenenrechten auf Löschung, Sperrung und Berichtigung hielten alle 
Probanden für vollkommen oder nahezu vollkommen sinnvoll. 
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12.4 Verständlichkeit und Nutzen der 
Unverkettbarkeitsmetriken 


Im Rahmen der Nutzerevaluation wurde auch die Einstellung der Probanden zur 
Unverkettbarkeitsmetrik abgefragt. Dazu wurde ihnen zuerst der in Anhang G.3 
abgedruckte Erläuterungstext vorgelegt. Der Erläuterungstext ist identisch mit 
dem in PrivacyInsight hinterlegten. Die Probanden konnten gleichzeitig einen 
Blick auf die reale Einbindung der Metrik in Form von Zustandsbalken werfen. 


Von den 31 Probanden waren 21 der Meinung, das Konzept der Unverkett- 
barkeitsmetrik verstanden zu haben. 7 Probanden waren sich aufgrund der 
gegebenen Kurzbeschreibung nicht sicher. Dass ein Proband der Auffassung 
ist, die Metrik verstanden zu haben, heißt noch nicht, dass dies tatsächlich der 
Fall ist. In der Akzeptanz von Datenverarbeitungsverfahren spielt allerdings 
das wahrgenommene Verhalten eines Systems eine viel größere Rolle als das 
tatsächliche. 


Nichtsdestotrotz wurde versucht, in Interviews nach der Bearbeitung der 
Fragebögen abzuklopfen, ob die Metrik tatsächlich verstanden wurde. Die 
Probanden wurden aufgefordert, den Studienleitern im Rahmen eines finalen 
Feedbacks die Bedeutung der Metrik so zu erklären, wie sie sie verstanden 
haben. Dabei hat sich der Eindruck ergeben, dass subjektive und objektive 
Wahrnehmung übereinstimmen. Verallgemeinerbar ist dieser unsystematische 
Eindruck allerdings nicht. 


Von den 21 Probanden, die die Metrik verstanden hatten, hielten 6 die Metrik 
nicht für hilfreich, für 9 war sie eine nützliche Entscheidungsgrundlage für 
ihre Opt-out-Möglichkeit. Insgesamt ein zufriedenstellendes, wenn auch nicht 
gutes, Ergebnis für eine bis dato unbekannte Entscheidungshilfe. 


Die Probanden wurden mit Unlinkability-Werten von 76 %, 80 %, 86 % und 
89 % (Speicher- und Verarbeitungsrelation, Datenflussrelation, Verknüpfungs- 
relation und Identifikationsrelation) konfrontiert. Unter dieser Maßgabe wollte 
kein Proband direkt auf das Datenschutzauskunftssystem verzichten. 8 Pro- 
banden waren allerdings unentschieden. 
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Ein Schwellwert, ab dem eine überwiegende Anzahl der Betroffenen auf das 
Datenschutzauskunftssystem verzichten wiirde, wurde nicht ermittelt. Dies 
wäre eine interessante Aufgabe für eine zukünftige Nutzerbefragung. 


12.5 Erwartungen der Betroffenen 


Neben den demographischen Daten wurde am Ende der Studie abgefragt, wen 
die Probanden in der Verantwortung für den Schutz personenbezogener Daten 
sehen. Im Verhältnis zwischen Staat und Bürger sowie Staat und Unternehmen 
waren sich die Probanden uneins. Im Mittel wurden beide Akteure in gleichem 
Maße in die Pflicht genommen, wobei die Streuung so stark war, dass von 
keinem eindeutigen Bild gesprochen werden kann. Anders sah die Situation im 
Verhältnis zwischen Unternehmen und ihren Kunden aus. Nur 3 Probanden 
(10%) sahen eher den Kunden in der Pflicht. Weitere zwei Probanden (6 %) 
sahen die Verantwortung in gleichem Maße bei Kunden und Unternehmen. Alle 
anderen (84 %) sahen vor allem das Unternehmen in der Pflicht, 9 Probanden 
(29 %) sogar ausschließlich. 


Daraus ergibt sich ein Widerspruch zwischen rechtlicher und tatsächlicher 
Sicht auf den Datenschutz. Während sich Bürger und Unternehmen als Private 
zunächst gleichberechtigt gegenüberstehen, ist der Staat Grundrechtsverpflich- 
teter und muss daher für das Recht auf informationelle Selbstbestimmung 
einstehen. 


Die Probanden sehen dagegen das primäre Machtgefälle zwischen Kunden und 
Unternehmen. Die Datenindustrie wird auch nach Snowden! als die größere 
Gefahr gesehen. 


Eine Umfrage von Statista bestätigt die Wahrnehmung.” Während 2009 noch 
44% der Befragten den Staat als den für den Datenschutz im Internet Ver- 
antwortlichen benennen, sind es 2014 nur noch 15 %. Auf der anderen Seite 


1 Preneel 2015. 
2 http://de.statista.com/statistik/daten/studie/243353/umfrage/verantwortung-fuer-den- 
datenschutz-im-internet, abgerufen am 9. Mai 2017. 
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Erhebungs- und Übermittlungsvorgänge 


+ Datenfliisse zu 
Auftragsdaten- 
verarbeitern 


Informationen zu Datenfliissen 
sind generell unnötig 


+ Datenflüsse in IT-Systemen | 
zwischen Anwendungen 
und Speicherbereichen 


+ Datenflüsse zwischen IT-Systemen 


+ Datenflüsse zwischen Abteilungen 


Abbildung 12.5: Erwarteter Detailgrad der Informationen über Datenflüsse im Rahmen einer 
Auskunft (im Uhrzeigersinn) 


versiebenfacht sich die Zahl der Befragten, die Anbieter von Online-Diensten 
und Hersteller von Hard- und Software in der Pflicht sehen, auf 22%. Die 
Fragestellung ist eine etwas andere, doch das Ergebnis zeigt in die gleiche 
Richtung. 


Welche Schlussfolgerungen ergeben sich daraus für das Recht auf Auskunft? 
Eine weitere Differenzierung zwischen Unternehmen und Staat wurde nicht 
vorgenommen. Teil des Fragebogens war jedoch die Frage, welche Informati- 
onstiefe die Probanden im Rahmen einer Auskunft nach $ 34 BDSG erwarten 
würden. Wie in Abbildung 12.5 abzulesen, wären 87% der Probanden (26 
Personen) damit zufrieden, wenn ihnen Informationen zu Erhebungs- und 
Übermittlungsvorgängen, Datenflüsse zu Auftragsdatenverarbeitern und Da- 
tenflüsse zwischen Abteilungen mitgeteilt würden. Dies entspricht in etwa 
den rechtlichen Vorgaben. Nutzererwartungen und Datenschutzrecht sind in 
Deckung. 
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12.6 Zwischenfazit 


Die Auskunftsplattform PrivacyInsight hat sich im Rahmen der Studie als 
überlegen gegenüber bereits existierenden Auskunftsverfahren aus Literatur und 
Praxis herausgestellt. Der Funktionsumfang des Datenschutzauskunftssystems 
wurde gut angenommen und positiv bewertet. PrivacyInsight erfüllt die in 
Hypothese 95 formulierten Hoffnungen. 


Die Probanden als typische Nutzer der ersten Stunde halten die Integration 
von Auskunft und weiteren Betroffenenrechten für den richtigen Weg. Die 
Unverkettbarkeitsmetrik wird von manchen als hilfreiche Information, von 
machen noch mit einer gewissen Ambivalenz betrachtet. Inwiefern von einem 
Opt-out Gebrauch gemacht würde, ist noch nicht absehbar. 
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Die vorliegende Arbeit liefert eine interdisziplinäre Gesamtbetrachtung zur 
Datenschutzauskunft in drei Themenfeldern. Sie stellt vor, wie sich die Umset- 
zung des Rechts auf Auskunft im Hinblick auf den technologischen Fortschritt 
entwickeln könnte. 


Herausforderung ist der informationelle Kontrollverlust des modernen Men- 
schen. Er wird durch drei Trends geprägt.! Erstens werden Daten an immer 
mehr Stellen durch immer neue Mechanismen und Sensoren erhoben. Bei 
jedem Besuch einer Website, mit jeder E-Mail und bei jeder Bewegung durch 
den öffentlichen Raum unter der Beobachtung von Kameras? und Smartphones 
werden neue personenbezogene Daten erhoben. Zweitens ist der Austausch 
und die Speicherung personenbezogener Daten so leicht möglich wie noch nie. 
In der Cloud ist nahezu unbegrenzter Speicher für jedermann verfügbar. Die 
Bandbreite der Übertragungskanäle erlaubt es, von überall jederzeit auf alle 
gespeicherten Daten zuzugreifen. Drittens erhöhen sich die Möglichkeiten der 
Auswertung personenbezogener Daten signifikant. Durch die Anwendung von 
Big-Data-Techniken können aus großen Datenschätzen neue Informationen ab- 
geleitet werden. Methoden der künstlichen Intelligenz erlauben die Erkennung 
komplexer Muster. 


In allen drei Dimensionen muss sich auch die Erbringung der Datenschutzaus- 
kunft weiterentwickeln, um den prognostizierten Kontrollverlust zu verhindern. 
Personenbezogene Daten müssen bereits zum Erhebungszeitpunkt identifiziert 


! Seemann 2016, 129 £. 
2 Nicht mehr nur als stationäre (intelligente) Videoüberwachung, sondern auch durch Drohnen, 
Dashcams, Wearables ä la Google Glass und Smartphones mobil eingesetzt. 
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und der späteren Auskunft zugänglich gemacht werden. Die Erfassungsme- 
chanismen miissen in allen datenerhebenden Systemen integriert sein. Die 
Speicherung der Historie eines personenbezogenen Datums, der Provenan- 
ce, muss so organisiert sein, dass eine Auskunft bei Bedarf unverzüglich 
generiert werden kann. Der Zugriff des Betroffenen auf die Auskunft muss 
unkompliziert, schnell, benutzerfreundlich und nachvollziehbar möglich sein. 
All dies lässt sich nur durch ein automatisiertes Datenschutzauskunftssystem 
bewerkstelligen. Dies ist das erste Themenfeld der vorliegenden Arbeit. 


Gleichzeitig entsteht ein Profilbildungspotential durch das Auskunftsverfahren 
selbst. Die Architektur eines Datenschutzauskunftssystems muss so entworfen 
werden, dass die Verkettung personenbezogener Daten nur für die Auskunft 
stattfindet. Der Betroffene muss in die Lage versetzt werden, zu entschei- 
den, welchen Kompromiss zwischen Transparenz und Unverkettbarkeit er 
einzugehen bereit ist. Damit ist das zweite Themenfeld umrissen. 


Die technologische Entwicklung wird von einem Umbruch der rechtlichen 
Grundlagen des Datenschutzes begleitet. Der zentrale Faktor ist die Europäisie- 
rung des Datenschutzes. Nationale Regelungen werden durch die Datenschutz- 
Grundverordnung abgelöst. Dadurch entstehen neue Betroffenenrechte wie das 
Recht auf Datenübertragbarkeit. Dieses Recht ist ein Beispiel für die Konver- 
genz des Wettbewerbs- und Datenschutzrechts auf nationaler und europäischer 
Ebene. Die Einordnung aller rechtlichen Aspekte ist das dritte Themenfeld. 


Die vorliegende Arbeit trägt mit den im folgenden Abschnitt zusammengefassten 
Ergebnissen zur Klärung und Bewältigung der aufgeworfenen Problemstellun- 
gen bei. 


13.1 Zusammenfassung der Ergebnisse 


Gemäß der Rechtsprechung des Bundesverfassungsgerichts muss das 
Datenschutz-Schutzziel der Transparenz nicht zwingend durch ein Recht 
auf Auskunft umgesetzt werden (41). Die Datenschutzauskunft ist eine 
Umsetzungsvariante des Rechts auf Kenntnisnahme, verankert im Recht auf 
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informationelle Selbstbestimmung des Art. 2 I i. V. m. Art. 1 I GG. Der Gesetz- 
geber hat sich hingegen für ein Recht auf Auskunft entschieden. In den §§ 19, 34 
BDSG legt er für öffentliche und nicht-öffentliche Stellen nahezu inhaltsgleiche 
Anforderungen fest. Anders stellt sich die Situation europarechtlich dar. Das 
Recht auf Auskunft ist in Art. 8 Abs. 2 Satz 2 GRCh explizit kodiert (91). 
Folgerichtig findet sich auch in der DSGVO ein Recht auf Auskunft. 


Die DSGVO ändert nichts daran, dass das Recht auf Auskunft jedem Be- 
troffenen ohne weitere Voraussetzungen zusteht. Sowohl nach den bisherigen 
Regelungen als auch nach denen der DSGVO ist es möglich, eine Auskunft auf 
einer elektronischen Plattform zu erteilen, soweit diese angemessen gesichert 
ist und eine Downloadmöglichkeit bietet. Im Rahmen des Rechts auf Daten- 
übertragbarkeit legt die DSGVO fest, dass solch eine Downloadmöglichkeit die 
stellenübergreifende Nutzung personenbezogener Daten ermöglichen soll. Der 
Betroffene soll selbst in der Lage sein, zu entscheiden, welche verantwortliche 
Stelle welche Datenverarbeitung für ihn übernimmt. Datenschutz hat insofern 
eine marktgestaltende Wirkung. Verbraucherschutzrecht und Datenschutzrecht 
verbinden sich. 


Die Auskunft umfasst die gespeicherten personenbezogenen Daten, den Zweck 
der Speicherung, den Speicherort sowie Herkunft und Empfänger. Aufgrund des, 
durch die DSGVO bestätigten, weiten Empfängerbegriffs ist eine durchgängige 
Nachvollziehbarkeit der Flüsse personenbezogener Daten erforderlich (92). Es 
sind alle Stellen zu nennen, die personenbezogene Daten zu einem dezidiert 
unterschiedlichen Zweck verarbeiten sowie der zwischen ihnen stattfindende 
Datenaustausch. 


Diesen Anforderungen wird die Praxis gegenwärtig nicht gerecht. Die durch- 
geführte Studie zeigt, dass selbst grundlegende Aspekte, wie der Zweck der 
Speicherung, nicht von allen Unternehmen in ihre Auskunft mitaufgenommen 
werden. Eine Nachvollziehbarkeit der stattfinden Datenflüsse ist in keinem Fall 
gegeben. 


Solange Unternehmen keine Sanktionen fürchten müssen ist fraglich, wie 
schnell flächendeckende Rechtskonformität hergestellt wird. Die DSGVO gibt 
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den Aufsichtsbehörden neue Instrumente in die Hand. Der monetäre Sank- 
tionsrahmen wird empfindlich erhöht. Der nationale Gesetzgeber versucht 
gleichzeitig neue Sanktionsmöglichkeiten auf wettbewerbsrechtlicher Ebene 
zu schaffen. Die Neufassung des UKlaG soll die Abmahnung von Daten- 
schutzverstößen ermöglichen. Der Auskunftsanspruch ist davon jedoch nicht 
erfasst. 


Das entworfene Ableitungsmodell EVAL unterstützt die Konzeption eines 
Datenschutzauskunftssystems. Es erlaubt den systematischen Übergang 
von der rechtlichen Analyse zur technischen Realisation (R1). Zu diesem 
Zweck führt es die analytischen Ebenen der Datenschutz-Schutzziele, der 
datenschutzrechtlichen Anforderungen und Kriterien sowie der technischen 
Anforderungen ein. Für den Auskunftsanspruch sind die einzelnen Elemente 
dieser Ebenen vollständig beschrieben. Das in dieser Arbeit vorgestellte 
Datenschutzauskunftssystem erfüllt diese Anforderungen (6). 


Das Datenschutzauskunftssystem trägt in den oben genannten drei Dimensio- 
nen dazu bei, dass verantwortliche Stellen die Erteilung einer Auskunft besser 
umsetzen können. Grundlage ist die vorgestellte Architektur, die Erfassung, 
Verarbeitung, Speicherung und Auswertung des Umgangs mit personenbe- 
zogenen Daten, die Personal-Data-Provenance, integriert. Die Verbindung 
aus Provenance-Tracking und Usage-Control sorgt dafür, dass die Auskunft 
und die weiteren Betroffenenrechte auf Löschung, Sperrung und Berichtigung 
gemeinsam realisiert werden (A2). Ist die Provenance eines Datums bekannt, 
ist auch bekannt, wo UC-Policies die übrigen Betroffenenrechte durchsetzen 
müssen. 


Die Ereignisse der Datenverarbeitung von einmal erkannten personenbezo- 
gene Daten werden von einem PEP abgefangen. Die Ereignisse werden mit 
Hilfe einer generischen Semantik beschrieben. So können die Auswirkung 
eines Ereignisses auf das Informationsflussmodell für neu hinzukommende 
Applikationen direkt bestimmt werden. Die Personal-Data-Provenance speist 
sich direkt aus dem, um den Betroffenen erweiterten, Informationsflussmodell. 
Das Data-Provenance-Modell dieser Arbeit ist, im Gegensatz zu beispielsweise 
dem aus A4Cloud, datenzentriert. Es werden keine Verarbeitungsprotokolle, 
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sondern Strukturen fiir jedes einzelne personenbezogene Datum gespeichert. 
Die Personal-Data-Provenance hat eine Baumstruktur mit den Repräsentatio- 
nen der einzelnen Datenverwendungen als Knoten und den temporären und 
räumlichen Beziehungen als Kanten. Unterschiedliche Repräsentationstypen 
erlauben die Erfassung der Provenance gemäß der datenschutzrechtlichen 
Anforderungen (3). Die Präzision des Trackings und damit der Provenance ist 
stark davon abhängig, ob PEPs für alle datenverarbeitenden Systeme vorhanden 
sind. Noch nicht abbildbar ist eine Vermischung personenbezogener Daten in 
einem gemeinsamen Container, so dass eine anschließende Trennung wieder 
möglich ist (4 &3). 


Würden alle technisch erfassbaren Verarbeitungszustände in der Personal-Data- 
Provenance gespeichert, würde dies dem Grundsatz der Datenminimierung 
zuwiderlaufen. Mit Hilfe von Lösch- und Abstraktionsregeln kann erreicht 
werden, dass nur genau die Provenance gespeichert wird, die für eine Auskunft 
erforderlich ist. Tests zeigen, dass diese Regeln potentiell zu einer besseren 
Speichereffizienz führen (93). Der Speicherbedarf wächst sowohl im Verhältnis 
zu den Ereignissen als auch zu der Anzahl der personenbezogenen Daten 
maximal linear. Das System ist auch bei hoher Ereignisfrequenz und Datendichte 
noch benutzbar. Der Overhead der Provenance ist kaum spürbar. Allerdings 
können die verwendeten PEPs die datenverarbeitenden Systeme merklich 
bremsen. 


Die Personal-Data-Provenance ist im Sinne einer informationellen Gewalten- 
teilung dezentral auf den einzelnen datenverarbeitenden Systemen gespeichert. 
Finden systemübergreifende Informationsflüsse statt, werden die dazugehörigen 
Ereignisse anhand einer systemübergreifenden Semantik interpretiert. Dazu 
wurden in dieser Arbeit die Ideen von Lovat! und Kelbert? erweitert. Scopes 
sind nun auch zwischen Systemen möglich. Anwendungen können dynamisch 
gekoppelt werden. 


Erst wenn der Betroffene eine Auskunft anfordert, wird die Personal-Data- 
Provenance aggregiert. Dazu wird der Provenance-Baum traversiert und anhand 


! Lovat 2015. 
2 Kelbert/Pretschner 2015. 
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der Repräsentationen, die eine Datenweitergabe beschreiben, zusammengefügt 
(#4). Die Auskunftsplattform PrivacyInsight ist eine interaktive Webappli- 
kation. Sie erlaubt es dem Betroffenen, Flüsse personenbezogener Daten in 
anpassbarer Informationstiefe nachzuverfolgen. Einblicke in die gespeicherten 
personenbezogenen Daten sind genauso möglich, wie die Wahrnehmung 
der Betroffenenrechte auf Löschung, Sperrung und Berichtigung. Eine 
Nutzerstudie zeigt, dass PrivacyInsight der bisher besten Auskunftsplattform, 
GenomSynlig,' in allen Belangen überlegen ist. Mit einer kurzen Einführung 
war allen Probanden auch der erweiterte Funktionsumfang von PrivacyInsight 
gut zugänglich (95). Der Umgang mit personenbezogenen Daten wird für die 
Betroffenen nachvollziehbar. 


Ein Datenschutzauskunftssystem hat Auswirkungen auf die Profilbildungs- 
fähigkeit von Stellen im auskunftspflichtigen Unternehmen. Eine Metrik für 
Unverkettbarkeit macht diese sichtbar. Diese Arbeit geht dabei in mehrfacher 
Hinsicht über den Stand der Forschung hinaus. Erstens wurde die Definition 
eines Grades von Unverkettbarkeit so verallgemeinert, dass sie für beliebige 
Angreifer, Entitäten, Systeme und Verkettungsrelationen instanziierbar ist. 
Zweitens wurde die Metrik für das Szenario eines Datenschutzauskunfts- 
systems in 4 Varianten instanziiert (X5). Drittens wurde aufgezeigt, wie die 
Metrik konkret berechnet werden kann. Dazu wurden sowohl mathematisch- 
analytische Überlegungen angestellt als auch eine neue Heuristik entwickelt. 
Die Berechenbarkeit wurde anhand einer Fallstudie belegt. Der Aufwand ist 
jedoch stark von der Größe der Datensätze abhängig. 


Zuletzt wurde untersucht, welche Konsequenzen aus einer Metrik für Un- 
verkettbarkeit gezogen werden können. Es ist schwierig, verschiedene Sys- 
temarchitekturen miteinander zu vergleichen. Die Metrik gibt nur Auskunft 
über die Unverkettbarkeit in einer bestimmten Situation zu einem bestimmten 
Zeitpunkt. Nur in Extremfällen können aus Szenarien Schlussfolgerungen für 
ganze Systemarchitekturen abgeleitet werden. Die Architektur Insynd? ist der 


' Angulo et al. 2015. 
2 Pulls/Peeters 2015. 
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Architektur dieser Arbeit in manchen Metriken überlegen, sofern man in Kauf 
nimmt, dass jeder Betroffene vor einer etwaigen Erhebung personenbezogener 
Daten in einen Schlüsselinitialisierungsprozess eingebunden werden muss. 


Gut geeignet ist die Metrik hingegen, um den Betroffenen zu einem festen 
Zeitpunkt über seine Unverkettbarkeitssituation zu informieren. Fraglich ist 
in solch einem Zusammenhang, wie gut ein Laie eine komplexe Metrik 
interpretieren kann. Die durchgeführte Nutzerstudie zeigt, dass das Konzept 
der Metrik für einen Großteil der möglichen technikaffinen Erstverwender 
verständlich ist. Aussagen über die Bedeutung bestimmter Werte lassen sich 
daraus noch nicht ableiten (4.94). 


Die Metrik wurde in PrivacyInsight eingebunden und mit einer Opt-out- 
Möglichkeit für das Provenance-Tracking verknüpft (94). Rechtlich ist so eine 
Möglichkeit umstritten, jedoch vertretbar. Das Recht auf Auskunft ist zwar nach 
dem Gesetzeswortlaut unabdingbar. Aus verfassungs- und europarechtlichen 
Gründen kann dies jedoch für den Sonderfall eines Datenschutzauskunftssys- 
tems nicht uneingeschränkt gelten. Die befragten Probanden würden jedenfalls 
auf solch eine Möglichkeit nur ungern verzichten. Ob sie sie letztendlich 
wahrnehmen, ist eine andere Sache. 


13.2 Abgrenzung 


13.2.1 Verwandte Arbeiten 


Ableitung datenschutzrechtlicher Anforderungen Kiyavitskaya, Krausovä 
und Zannone! begründen, warum die Ableitung rechtlicher Anforderungen 
schwierig ist. Die von ihnen angesprochenen Punkte wie die Mehrdeutigkeit 
des Rechts und die unterschiedliche Methodik in Rechtswissenschaft und 
Informatik werden von dieser Arbeit adressiert. 


! Kiyavitskaya/Krausovä/Zannone 2008. 
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Hammer, Pordesch und Roßnagel, ! Schwenke,? Schulz? und Kahlert* verwen- 
den die Methode KORA zur Konkretisierung rechtlicher Anforderungen an 
IT-Systeme. Bei allen werden die Schwächen der Methode KORA deutlich. 
Die von ihnen als „rechtliche Kriterien“ bezeichneten Begriffe sind nur allge- 
meine Zielvorgaben. Die eigentliche Auslegung des Rechts durch sprachliche, 
logische, systematische, historische oder teleologische Methoden findet zum 
Großteil erst auf der Ebene der „technischen Gestaltungsziele“ statt. Dort sollte 
allerdings schon der Wechsel zur technischen Sprache stattgefunden haben. 
Echte, detaillierte technische Anforderungen werden nicht erreicht. Das in die- 
ser Arbeit neu eingeführte EVAL-Modell führt zusätzliche Ableitungsschritte 
ein und präzisiert die Abgrenzung zwischen diesen. Darüber hinaus findet die 
Ableitung bis hin zur Implementierung statt. 


Unter vielen diskutieren Spiekermann und Cranor°, Langheinrich® und Han- 
sen’ die bei der Entwicklung datenschutzfreundlicher Systeme zu verfolgenden 
grundsätzlichen Herausforderungen und Ziele. Aus diesen leiten sie ad hoc 
technische Anforderungen ab. Sie tun dies jedoch nicht durch eine verallgemei- 
nerbare systematische Ableitung wie in EVAL. Ihr Beitrag liegt vielmehr darin, 
die Bedeutung und Anwendung von Datenschutz-Schutzzielen für Entwickler 
greifbar zu machen. 


Probst? listet generische Maßnahmen zur Adressierung der Datenschutz- 
Schutzziele auf. Da sie nicht als Anforderungen an ein konkretes System 
entworfen wurden, pendeln sie irgendwo zwischen den rechtlichen Anforde- 
rungen und den rechtlichen Kriterien von EVAL. Ist für ein zu entwickelndes 
System aus zeitlichen oder finanziellen Gründen keine vollständige EVAL- 
Analyse möglich, ist diese Art der Auflistung die nächstbeste Alternative. 


! Hammer/Pordesch/Roßnagel 1993. 

? Schwenke 2006. 

3 Schulz et al. 2011. 

4 Kahlert, DuD 2014, 86. 

5 Spiekermann/Lorrie Faith Cranor 2009. 
6 Langheinrich 2001. 

7 Hansen 2011. 

8 Probst, DuD 2012, 439. 
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Aldeco-Pérez und Moreau! schlagen vor, Provenance für die Auditierung der 
Verwendung personenbezogener Daten heranzuziehen. Sie leiten aus dem 
UK Data Protection Act sieben Prinzipien fiir solch eine Provenance ab. 
Ergänzend schlagen sie eine generische Architektur für die Auditierung mit 
Hilfe einer Personal-Data-Provenance vor. Darüber hinaus wird ausgeführt, wie 
geeignete Queries auszusehen haben. Demgegenüber nimmt diese Arbeit eine 
weit umfangreichere Ableitung von Anforderungen an eine Provenance für den 
Auskunftsanspruch vor. Die Architektur dieser Arbeit verbindet Usage-Control 
und Provenance und wurde prototypisch implementiert. Da die Art der Abfrage 
einer Personal-Data-Provenance zum Zweck der Auskunft vordefiniert ist, sind 
Queries nicht Teil dieser Arbeit. 


Informationsfluss- und Provenance-Modell Lovat, Oudinet und Pretsch- 
ner? verwenden einen ähnlichen Graphen je Datum, wie er in dieser Arbeit im 
Provenance-Modell Verwendung findet, um die gegenwärtige „Menge“ eines 
sensitiven Datums in einem Container zu bestimmen. Dagegen hinterlegt diese 


Arbeit die Historie der Informationsflüsse in einer Provenance-Datenstruktur. 


Die Ideen von Lovat? zu strukturierten Informationsflüssen sind eine Ergänzung 
der Modelle in dieser Arbeit. Eine zukünftige Einbindung, um die Struktur 
der Provenance zwischen unterschiedlichen Verarbeitungskomponenten zu 
erhalten, ist denkbar und sinnvoll. Das Modell für schichtenübergreifende 
Informationsflüsse von Lovat* wird in dieser Arbeit aufgenommen und auf 
systemübergreifende Informationsflüsse verallgemeinert. Ergänzend wird es 
einer Beschreibung in der Informationsflusssemantik zugänglich gemacht. 


Die Abgrenzung des systemübergreifenden Informationsfluss- und Provenance- 
Trackings gegenüber den Arbeiten von Kelbert? wurde bereits in Kapitel 8.1 


1 Aldeco Pérez/Moreau 2008. 

2 Lovat/Oudinet/Pretschner 2014. 

3 Lovat/Kelbert 2014. 

4 Lovat 2015. 

5 Kelbert/Pretschner 2013; Kelbert/Pretschner 2014; Kelbert/Pretschner 2015. 
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vorgenommen. Zusammenfassend ermöglicht der Ansatz von Kelbert im Gegen- 
satz zu dieser Arbeit die systemübergreifende Durchsetzung von UC-Policies. 
Die Konzepte dieser Arbeit lassen dafür das Tracking von Informationsflüssen 
aus Anwendungen heraus zu. Die Enden einer Verbindung können anhand 
beliebiger Identifikatoren zugeordnet werden, die in einer Informationsflussse- 
mantik hinterlegt sind. Darüber hinaus wird die Provenance der Datenflüsse 
aufgezeichnet. 


Des Weiteren existieren bereits Konzepte zur Propagierung von Taintmarken 
über Systemgrenzen hinweg. NEON! ist ein Monitor für virtuelle Maschinen 
und unterstützt Taintmarken zum Tracken von Informationsflüssen auf Bytee- 
bene. Diese Art der Repräsentation von Taintmarken limitiert die mögliche 
Anzahl getrackter Daten je Byte auf 32. Dagegen erlaubt es das in dieser Arbeit 
verwendete Informationsflussmodell theoretisch unbegrenzt viele Daten zu 
tracken. Tainting auf Netzwerkebene findet zwar nicht auf Byteebene, sondern 
pro Netzwerkpaket mit bis zu 256 Daten pro Paket statt. Die einzelnen, im 
Netzwerkpaket transportierten Bytes lassen sich auf Empfängerseite allerdings 
nicht mehr unterscheiden. SeeC? speichert je Prozess eines IT-Systems Taint- 
marken in einem Schattenspeicher und erzeugt für jeden Socket eine write 
queue für Taintmarken zu Datenflüssen über TCP/IP. Bei SeeC ist die mögliche 
Anzahl getrackter Daten je Byte ebenfalls auf 32 beschränkt. Generell gilt 
für die Propagierung von Taintmarken, dass sich daraus nicht die in dieser 
Arbeit erforderliche Provenance ergibt. Es wird nur die Zuordnung der Daten 
im aktuellen Systemzustand gespeichert. 


GARM? erlaubt mit Hilfe von Application-Rewriting ein Provenance-Tracking 
über Systemschichten hinweg. Insofern ist es eine hartcodierte Lösung für 
bestimmte Abstraktionsschichten. GARM differenziert nicht zwischen Daten 
und Containern und lässt kein systemübergreifendes Proveance-Tracking zu, 
wie es diese Arbeit bietet. 


1 Q. Zhang et al. 2010. 
? Kim et al. 2009. 
3 Demsky 2009; Demsky 2011. 
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Muniswamy-Reddy et al.! integrieren in ihrem Framework Provenance- 
Collection und -Storage über Systemschichten hinweg. Das Framework baut 
auf dem Provenance-Dateisystem PASS? auf. Es ist keine generische Lösung, 
wie die in dieser Arbeit vorgestellte, sondern ist spezifisch auf die drei Schich- 
ten Dateisystem, Browser und Workflow-Engine zugeschnitten. Insbesondere 
beruht es auf der Betriebssystemintegration von PASS, während der Ansatz 
dieser Arbeit auch auf Anwendungsebene funktioniert. 


Herkenhöhner et al. stellen eine Architektur und ein Nachrichtenformat vor, 
um die für das Recht auf Auskunft erforderliche Provenance in organisations- 
übergreifenden Webservices automatisiert zu sammeln und dem Betroffenen 
zur Verfügung zu stellen. Sie stellen ausschließlich ein Nachrichtenformat für 
verteilte Data-Provenance-Systeme vor, entwerfen und implementieren jedoch 
kein solches System. Diese Arbeit geht jedoch alle Schritte, von der Anforde- 
rungsanalyse bis zur Implementierung. Nachrichtenformate wurden in dieser 
Arbeit nicht auf der Ebene von Webservices, sondern implementierungsnah 
definiert. 


Kapitel 5.1 listet eine Reihe weiterer Provenance-Systeme auf, die spezifisch 
für bestimmte Abstraktionsschichten sind und sich an einen speziellen An- 
wendungsfall wie das wissenschaftliche Rechnen richten. All diese Systeme 
sind nicht geeignet, um zielgerichtet die Provenance personenbezogener Daten 
gemäß der datenschutzrechtlichen Anforderungen zu sammeln. Diese Arbeit 
stellt einen generischen Ansatz vor, der auf beliebigen Abstraktionsschichten 
funktioniert und richtet die Art der Provenance speziell auf den Anwendungsfall 
der Datenschutzauskunft aus. 


Pulls et al.* stellen das kryptographische Schema Insynd vor. Es ermöglicht, 
Personal-Data-Provenance zu sammeln, ohne die Verknüpfungen zwischen 
den einzelnen Logs zu offenbaren. Wie in Kapitel 9.10.3 diskutiert, kann mit 


! Muniswamy-Reddy et al. 2009. 

? Holland et al. 2008. 

3 Herkenhöner et al. 2010. 

4 Pulls/Peeters/Wouters 2013; Pulls/Peeters 2015. 
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diesem Schema in gewissen Fallen der durch den Einsatz eines Datenschutzaus- 
kunftssystems entstehende Grad der Unverkettbarkeit verbessert werden. Der 
Ansatz hat allerdings den Nachteil, dass der Betroffene in den Setup-Prozess 
des Logging-Schemas involviert werden muss. Geklärt wird außerdem nicht, 
wie sich die Personal-Data-Provenance zusammensetzt und wie sie aggregiert 
werden kann. 


Die in Kapitel 5.1 gelisteten Arbeiten zur Sicherheit von Data-Provenance sind 
orthogonal zu dieser Arbeit. Die Sicherheit von Data Provenance wird gemäß 
der Annahmen in Kapitel 5.3.3 vorausgesetzt. Diese Arbeit liefert zu diesem 
Themenkomplex keine eigenen Beiträge. 


Ebenso liefert diese Arbeit keine eigenen Beiträge zu Usage-Control. Die in 
Kapitel 5.2 vorgestellten Forschungsergebnisse werden, aus den im selbigen 
Kapitel geschilderten Gründen, im Datenschutzauskunftssystem verwendet. 


Unverkettbarkeit Bestehende Arbeiten zur Bestimmung des Begriffs der Un- 
verkettbarkeit wurden bereits in Kapitel 9.1.1 vorgestellt. Gegenüber den dort 
erwähnten Definitionen ist die in dieser Arbeit verwendete Definition genauer. 
Sie benennt den Angreifer und die verwendeten Relationen für das „zusam- 
menführen“ personenbezogener Daten, Betroffener und datenverarbeitender 
Systeme. 


Die in Kapitel 9.1.2 vorgestellten Modelle zur Relationenunterscheidbarkeit 
haben alle den Nachteil, dass sie nach dem ‚„all-or-nothing“-Ansatz arbeiten. 
In einer Situation, in der ein gewisser Wissenszuwachs unabdingbar ist und 
in Kauf genommen wird, wie bei Auskunftssystemen, ist solch ein Ansatz 
jedoch nicht hilfreich. Die Metrik würde jederzeit trivial messen, dass die 
Unverkettbarkeit nicht gewahrt bleibt. Deshalb untersucht diese Arbeit relative 
Ansätze im Sinne entropiebasierter Unverkettbarkeitsmetriken. 


Eine erste entropiebasierte Metrik für Anonymität wird von Serjantov und 
Danezis! vorgestellt. Sie überführen das klassische „Anonymity Set“ auf ein 


l Serjantov/Danezis 2003. 
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nach den Wahrscheinlichkeiten der einzelnen Elemente der Menge gewichtetes 
Maß. Diaz et al.! ergänzen die Normierung des Anonymitätsmaßes. Diese 
Arbeit verwendet dagegen eine entropiebasierte Metrik zur Messung des Grads 
der Unverkettbarkeit. Dazu kann auf beliebige Relationen zuriickgegriffen 
werden. Die Metriken für Anonymität sind ein Spezialfall davon und können 
von der in dieser Arbeit vorgestellten Metrik mit abgebildet werden. 


Die Arbeiten von Steinbrecher und Köpsel? übertragen den informations- 
theoretischen Ansatz auf Unverkettbarkeit. Der Ansatz wird von Franz et al.° 
aufgegriffen. Beide beschränken die Metrik auf Äquivalenzrelationen. Franz et 
al. diskutieren zusätzlich bestimmte Sonderfälle von Beobachtungen, die ein 
Angreifer machen kann. Beispiele sind die Anzahl der Äquivalenzklassen, die 
Kardinalität der Äquivalenzklassen und die Aufdeckung der Verkettungsrelati- 
on für eine Teilmenge der betrachteten Entitäten. Fischer, Katzenbeisser und 
Eckert* beschränken sich ebenfalls auf Äquivalenzrelationen. Sie definieren 
ergänzend eine innere und äußere Struktur von Unverkettbarkeit. Diese Arbeit 
betrachtet beliebige Relationen. Eine Beschränkung auf Äquivalenzrelationen 
würde die Modellierung einer Beziehung zwischen personenbezogenen Daten 
und Betroffenen nicht zulassen. 


Pashalidis° verallgemeinert entropiebasierte Metriken von Äquivalenzrelatio- 
nen auf alle homogenen Relationen. Je nach Art der Relation bezeichnet er die 
Metrik unterschiedlich und führt Definitionen wie „Fairness“ und „Undurch- 
sichtigkeit“ ein. Diese Arbeit beschränkt sich auf Unverkettbarkeitsmetriken 
und betrachtet dabei beliebige Relationen. Darüber hinaus wird in dieser 
Arbeit das Hintergrundwissen des Angreifers explizit modelliert. Statt eines 
Maximum-Entropie-Priors wird ein angreiferspezifischer Prior bestimmt. 


! Diaz et al. 2003. 

? Steinbrecher/Köpsell 2003. 

3 Franz/Meyer/Pashalidis 2007. 

4 Fischer/Katzenbeisser/Eckert 2008. 
5 Pashalidis 2008. 
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Benutzeroberflächen zur automatisierten Auskunftserteilung Bestehende 
Ansätze zur Visualisierung der Verarbeitung personenbezogener Daten wurden 
bereits in Kapitel 1.1.2 vorgestellt. 


Das Data Disclosure Log von Kolter et al.! ist im Gegensatz zum in dieser Arbeit 
entwickelten Privacylnsight keine Auskunftsplattform, sondern greift nur auf 
die auf Betroffenenseite bereits vorhandenen Informationen zu. Gleiches gilt 
für Data Track.” Beide Tools sind darüber hinaus nicht webtauglich, sondern 
konventionelle Desktopanwendungen. 


Translucene Map von Kani-Zabihi und Helmhout? stellt Datenverarbeitungs- 
vorgänge ausschließlich auf Grundlage des Verfahrensverzeichnisses dar. 


GenomSynlig* ist das einzige in der Literatur existierende Tool zur interaktiven 
elektronischen Auskunftserteilung. Es liefert allerdings nur Informationen, 
wenn der Betroffene die Quelle der personenbezogenen Daten ist. Vom Infor- 
mationsgehalt her geht PrivacyInsight unter anderem in der Darstellung interner 
Datenflüsse und der Visualisierung aller Empfänger über GenomSynlig hinaus. 
Die Nutzerstudie des Kapitels 12 hat außerdem gezeigt, dass PrivacyInsight 
besser bedienbar ist. 


13.2.2 Grenzen der Arbeit 


Diese Arbeit beschränkt sich auf deutsches und europäisches Datenschutzrecht. 
Sie berücksichtigt die Rechtslage nach dem BDSG umfassend. Das dem im 
Grundsatz entsprechende Auskunftsrecht der DSGVO wird themenbezogen 
mitbetrachtet, jedoch bis auf das Recht auf Datenübertragbarkeit nicht vertieft 
behandelt.’ 


1 Kolter/Netter/Pernul 2010. 

? Wästlund/Fischer-Hübner et al. 2010. 

3 Kani-Zabihi/Helmhout 2012. 

4 Fischer-Hübner/Angulo/Pulls 2014; Angulo et al. 2015. 
5 Vgl. die Ausführungen in Kapitel 2.2.2. 
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Die angenommenen Voraussetzungen für die zuverlässige Erbringung einer 
automatisierten Auskunft werden in Kapitel 5.3.3 erörtert. Insbesondere die 
Annahme, dass das Datenschutzauskunftssystem in allen datenverarbeitenden 
IT-Systemen korrekt aufgesetzt sein muss, begrenzt die Nutzbarkeit der Ergeb- 
nisse dieser Arbeit. Aufgrund der Annahme ist eine automatisierte Auskunft 
beim Rückgriff auf Cloud-Auftragsdatenverarbeiter schwierig. Die verantwort- 
liche Stelle müsste den Cloud-Anbieter dazu verpflichten, seine verwendete 
Software anzupassen. Insbesondere bei großen, internationalen Anbietern ist 
dies kaum zu erreichen. Durch die DSGVO und Standardisierungsbemühungen 
könnte dieses Problem möglicherweise überwunden werden. 


Ein noch nicht vollständig gelöstes Problem des Informationsflusstrackings ist 
Label Creep. Kann bei einem Ereignis nicht festgestellt werden, ob ein perso- 
nenbezogenes Datum geflossen ist, muss konservativ angenommen werden, dass 
ein Fluss stattgefunden hat. Dadurch werden mehr Container als Speicherorte 
personenbezogener Daten aufgefasst als tatsächlich personenbezogene Daten 
enthalten. Ein Ansatz wie quantitatives Informationsflusstracking! kann nicht 
verfolgt werden. Es ist nicht möglich eine Informationsmenge zu definieren, ab 
der personenbezogene Daten nicht mehr sensibel oder vorhanden sind. 


Die in Kapitel 7.2 vorgestellten Abstraktionsregeln sind containerzentriert und 
nicht datenzentriert. Insofern ist es im Rahmen des Modells nicht möglich, 
für unterschiedlich sensible Daten den Detailgrad des Trackings zu variieren. 
Auskunftsrechtlich sind besonders sensible personenbezogene Daten zwar nicht 
anders zu betrachten als andere Daten. Anforderungen aus anderen Bereichen 
könnten jedoch möglicherweise zu einem anderen Ergebnis führen. 


Eine Einschränkung des im Kapitel 7.3 beobachten Vorteils von Abstrakti- 
onsregeln beim Speicherverbrauch ergibt sich daraus, dass Abstraktionsregeln 
nur wirksam sein können, wenn ein hoher Abstraktionsgrad der Provenance 
akzeptabel ist. Werden einzelne Verarbeitungsschritte zu vollständig unter- 
schiedlichen Zwecken durchgeführt, müssen diese Schritte in der Provenance 
erkennbar sein. Ein höherer Speicherbedarf ist dann die Folge. 


1 Lovat/Oudinet/Pretschner 2014. 
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Die Frage, wie unstrukturierte personenbezogene Daten zum Erhebungs- 
zeitpunkt erkannt und mit Provenance-Policies annotiert werden können, ist 
bisher ungelöst. Ihre Beantwortung ist Voraussetzung für eine vollständige 
automatisierte Auskunftserteilung. Erste Ideen existieren für die Detektion 
personenbezogener Daten in E-Mails.! 


Ein Bereich, in dem es besonders schwer ist Daten einem Betroffenen zu- 
zuordnen und so eine Auskunft zu ermöglichen, ist die Videoüberwachung. 
Zumindest in abgegrenzten, nicht-dffentlichen Bereichen könnten intelligente 
Systeme zukünftig eine Lösung bieten. Mitarbeiter könnten sich zu Arbeitsbe- 
ginn gegenüber einer Kamera ausweisen und dann im Nachhinein die über sie 
aufgezeichneten Bilder einsehen. 


Nur unvollständig gelöst ist die Frage nach Integrität und Verfügbarkeit bei 
gleichzeitiger Vertraulichkeit der Provenance. Die Arbeiten von Pulls bieten, ? 
mit den oben sowie im Kapitel 9.10.3 erwähnten Einschränkungen, eine 
Alternative zum hier verfolgten Konzept der dezentralen Speicherung. 


Die dem für Unverkettbarkeit verwendeten Angreifermodell zugrundeliegenden 
Annahmen werden in Kapitel 9.6 erläutert. Eine wesentliche Annahme ist die 
Unabhängigkeit der Flüsse zweiter Daten. Durch diese konservative Annahme 
wird ein möglicher Teil des Hintergrundwissens des Angreifers ausgeblendet. 
Es ist eine Vereinfachung, die so lange vorzuziehen ist, so lange tatsächliche 
Abhängigkeiten unbekannt sind. 


Die vorgestellte Metrik für den Grad der Unverkettbarkeit basiert auf einer 
rückschauenden Betrachtung. Für die Einbindung der Metrik bei der Erhebung 
personenbezogener Daten ist eine clientseitige Vorausberechnung notwendig. 
Die dafür erforderlichen Verfahren und Vorhersagemodelle sind Aufgabe 
zukünftiger Arbeiten. Der Betroffene könnte in der Konsequenz a priori 
entscheiden, ob er seine personenbezogenen Daten teilt und ob er ein Daten- 
schutzauskunftssystem nutzen möchte. 


l Bier/Prior 2014. 
2 Pulls/Peeters 2015. 
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Die Nutzerstudie des Kapitels 12 ermöglicht keine Aussage darüber, ob die 
Unverkettbarkeitsmetrik tatsächlich verstanden wurde und ob sie tatsächlich die 
Entscheidung des Betroffenen beeinflusst. Festgestellt wurde nur ein subjektiver 
Eindruck der Testpersonen. 


13.3 Ausblick 


Mit dem vorliegenden Datenschutzauskunftssystem ist ein großer Schritt hin 
zu einer, sowohl für verantwortliche Stellen als auch für Betroffene, besseren 
Umsetzbarkeit des Rechts auf Auskunft getan. Eine elektronische Auskunft 
entlastet die Unternehmen personell und gibt den Betroffenen gleichzeitig die 
Gewissheit, jederzeit in die Verarbeitung ihrer personenbezogenen Daten Ein- 
blick nehmen zu können. Eine elektronische Auskunft ist zuverlässiger als die 
bisherigen manuellen Verfahren und gibt dem Betroffenen die Gelegenheit, im 
Anschluss an die Auskunft, unmittelbar seine weiteren Rechte wahrzunehmen. 
PrivacyInsight hat bisher von allen Seiten außerordentlich positive Resonanz 
bekommen. 


Ein für die Zukunft wichtiges Handlungsfeld ist die Verknüpfung unterschied- 
licher datenverarbeitender Stellen. Die DSGVO hat dafür die Voraussetzungen 
geschaffen. Gemeinsam für die Verarbeitung Verantwortliche sind vorgesehen. 
Auftragsdatenverarbeiter sind schon seit jeher in den Verantwortungsbereich 
einer verantwortlichen Stelle miteinbezogen. Insofern ist es von höchstem 
Interesse, Schnittstellen für eine stellenübergreifende Auskunft zu schaffen. 
Nur so kann dem Betroffenen langfristig eine nahtlose Nachvollziehbarkeit der 
Datenverarbeitungsvorgänge geboten werden. 


So vorausschauend die DSGVO auch ist, sie ist nicht in jeder Hinsicht konse- 
quent. Sie führt zwar mit dem Recht auf Datenübertragbarkeit eine Regelung 
für den Austausch personenbezogener Daten ein, der Verordnungsgeber hat 
sich jedoch nicht durchringen können auch die notwendigen technischen 
Anforderungen zu stellen. ErwGr 68 stellt fest, dass es mit dem Recht auf 
Datenübertragbarkeit keine Pflicht zu kompatiblen IT-Systemen gibt. Eine so 
ausgestaltete Regelung ist stumpf. 
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13 Zusammenfassung und Ausblick 


Die Abstimmung zwischen den einzelnen Transparenzmaßnahmen könnte auch 
optimaler gestaltet sein. Unterrichtung, Benachrichtigung und Auskunft sind 
voneinander fast unabhängige Verpflichtungen. Es wäre in der Praxis sinnvoller, 
wenn die verantwortliche Stelle die passende Transparenzmaßnahme selbst 
wählen könnte. Wird der Betroffene bei einer einmaligen Datenverarbeitung 
vollständig unterrichtet, macht ein Auskunftsanspruch keinen Sinn mehr. 
Werden, wie bei Big Data in der Cloud, Daten vielfältigst verarbeitet und geteilt, 
macht es möglicherweise Sinn, den Betroffenen nicht über jede Übermittlung 
zu benachrichtigen, sondern ihm stattdessen eine einfache, stellenübergreifende 
Auskunftsmöglichkeit zur Verfügung zu stellen. 


Abschließend noch ein Satz zur Rechtsdurchsetzung. Die härteren Sanktionen 
der DSGVO wirken abschreckend. Solange die Aufsichtsbehörden personell 
schlecht aufgestellt sind,! ist der vom nationalen Gesetzgeber eingeschlagene 
Weg jedoch der effektivere. Die Regelungen des UKlaG sollten so präzisiert 
werden, dass sie auch die Auskunft und die übrigen Betroffenenrechte umfassen. 


! Nebenbei bemerkt sind stärkere und von jeder Kontrolle unabhängige Aufsichtsbehörden auch 
nicht der Traum eines jeden liberalen Staatstheoretikers. 
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A Studie zum Status Quo des 
Auskunftsrechts in der Praxis 


Die eigens erstellte,! Studie aus den Jahren 2015/16 verfolgte einen dualen, erst 
quantitativen und anschließend qualitativen, Ansatz. Die zunächst ausgewählte 
Stichprobe war weitaus größer und umfasste 612 Webseiten. Die Registrierung 
der entsprechenden Anzahl echter Personen und ihrer E-Mailadressen hätte 
einen enormen Aufwand bedeutet. Erfreulicherweise verpflichtet $ 13 Abs. 8 
TMG die Betreiber von Telemediendiensten, eine pseudonyme Nutzung der 
Dienste zu ermöglichen. Deshalb konnte auf künstlich erzeugte Persönlich- 
keitsprofile zurückgegriffen werden. Die umfangreichen Profile, die Namen, 
postalische Adresse, Alter, Geschlecht und Interessen umfassten, wurden mit 
dem Fake Name Generator erzeugt.” Für jedes Profil wurde nach dem Schema 
vorname.nachname@domain.de eine neue E-Mailadresse auf einem eigens 
dafür eingerichteten E-Mailserver erstellt. Die verwendete Domain wurde extra 
für die Studie registriert. Sie war somit noch unbekannt und es war kein zufällig 
an diese Domain adressierter Spam zu erwarten. Je Webseite wurde ein Profil 
registriert, wobei 151 Benutzeraccounts erstellt und 460 Newsletterregistrie- 
rungen vorgenommen wurden. Es wurden so viele personenbezogene Daten 
wie möglich angegeben, um den Datensatz so attraktiv wie möglich zu machen. 


Die repräsentative Stichprobe für die Studie wurde durch die Klassifikation 
der Wirtschaftszweige WZ 2008 des Statistischen Bundesamtes bestimmt.” 


! Bier/Kömpf/Beyerer 2017. 

2 http://www.fakenamegenerator.com. 

3 https://www.destatis.de/DE/Methoden/K lassifikationen/GueterWirtschaftklassifikationen/ 
klassifikationenwz2008.pdf?__blob=publicationFile, abgerufen am 9. Mai 2017. 


337 


A Studie zum Status Quo des Auskunftsrechts in der Praxis 


WZ 2008 basiert auf NACE! gemäß der Richtlinie 29/2002/EG und UN ISIC.? 
Die Klassifikation ist hierarchisch strukturiert und besteht aus 21 Abschnitten, 
88 Abteilungen, 272 Gruppen und 615 Klassen. Bei der Studie wurden nur 
Abschnitte mit einer Onlinepräsenz von mindestens 60 % gemäß den Angaben 
des statistischen Bundesamtes berücksichtigt.” Außerdem wurde Wert auf 
eine heterogene Zusammensetzung der Stichprobe gelegt. Deshalb wurden 
Abteilungen ausgeschlossen, in denen keine Unternehmen unterschiedlicher 
Größe gemäß der KMU-Kriterien (siehe Tabelle A.1), definiert in der Emp- 
fehlung der EU-Kommission 2003/361/EG, gefunden werden konnten. Die 
Angaben zu einzelnen Unternehmen wurden, wo möglich, dem Bundesan- 


zeiger entnommen.* Aus praktischen Gründen wurden weiterhin all jene 


Tabelle A.1: Definition der Kleinstunternehmen sowie der kleinen und mittleren Unternehmen 
(KMU-Definition)> 


Unternehmenskategorie Mitarbeiter Jahresumsatz Jahresbilanzsumme 


Mittlere Unternehmen < 250 < €50m <€43m 
Kleine Unternehmen < 50 <€10m <€10m 
Kleinstunternehmen < 10 <€2m <€2m 


Abteilungen ausgeschlossen, in denen die meisten Unternehmenswebseiten 
keine Möglichkeit zur Registrierung einer E-Mailadresse zuließen. Dieses 
Kriterium wurden anhand zufälliger Stichproben der Suchmaschinentreffer bei 
Eingabe der Abteilung als Suchbegriff überprüft. Von jedem Abschnitt wurden 
die Gruppen für die Studie ausgewählt, die die oben genannten Kriterien am 


1 Statistische Systematik der Wirtschaftszweige in der Europäischen Gemeinschaft, franz. Nomen- 
clature statistique des activites economiques dans la Communaute europeenne. 

? United Nations International Standard Industrial Classification of all Economic Activities. 

3 https://www.destatis.de/DE/ZahlenFakten/GesamtwirtschaftUmwelt/UnternehmenHandwerk/ 
IKTUnternehmen/Tabellen/04_AnteilUnternehmenInternetzugang_Website_IKT_ 
Unternehmen.html, abgerufen am 9. Mai 2017. 

4 http://www. bundesanzeiger.de. 

5 Empfehlung der Kommission vom 6. Mai 2003 betreffend die Definition der Kleinstunternehmen 
sowie der kleinen und mittleren Unternehmen, 2003/361/EG. 
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besten erfiillen. Insgesamt bestand die Stichprobe aus 612 Unternehmen in 
17 Gruppen, d.h. aus 36 Unternehmen je Gruppe. ! 


Die Studie wurde unter der Hypothese erstellt, dass ein gewisser Teil der Unter- 
nehmen personenbezogene Daten an Dritte weitergibt.” Die Nutzung der wei- 
tergegebenen personenbezogenen Daten, genauer gesagt der E-Mailadressen, 
durch Dritte könnte dann anhand auf dem Mailserver eingehender E-Mails 
erkannt werden. Anschließend könnte anhand der individuellen E-Mailadresse 
die Übermittlung der Daten zu dem Unternehmen zurückverfolgt werden, bei 
dem sie ursprünglich registriert wurde. Auf dieser Grundlage wäre es möglich, 
Auskunftsersuchen bei den ursprünglichen Unternehmen zu stellen und zu 
überprüfen, ob die Datenübermittlungen wahrheitsgemäß angegeben würden. 


Der Mailserver wurde zunächst für 102 Tage im Frühling und Sommer 2015 
überwacht und anschließend noch für weitere 6 Monate unter Beobachtung 
gestellt. Im ersten Zeitraum gingen nur unter fünf Adressen E-Mails von 
Domains ein, die nicht dem Unternehmen zugeordnet werden konnten, bei dem 
die Adresse ursprünglich registriert wurde. Im zweiten Beobachtungszeitraum 
hat sich daran nichts mehr geändert. In einem der Fälle konnte aufgeklärt 
werden, dass die Domain doch zum ursprünglichen Unternehmen gehört. 
Von den verbleibenden vier Fällen antworteten zwei Unternehmen, eine 
Online-Lotterie und ein Escort-Service, nicht auf das Auskunftsersuchen. Ein 
Unternehmen, ebenfalls eine Online-Lotterie, antwortete, dass es die Anfrage 
nicht verstünde, und ein Unternehmen, ein Online-Magazin, wies den Verdacht 
zurück, dass es Daten weitergegeben habe. Bei letzterem Unternehmen lässt 
die Art der eingegangenen E-Mails darauf schließen, dass Spammer an die 
registrierte Adresse gelangt sind. Von den verdächtigen Unternehmen waren 
drei nicht-deutscher Herkunft, während sich in der Stichprobe insgesamt nur 
etwa 12 % nicht-deutsche Unternehmen befanden. 


l Die Ausgewählten Gruppen waren, diejenigen mit dem WZ 2008 Code 11.0, 18.2, 45.1, 47.9, 
55.1, 56.1, 58.1, 58.2, 59.1, 63.1, 63.9, 79.1, 86.9, 90.0, 92.0, 93.1 und 96.0. 

2 Gestützt durch Skandale (Zeit Online, http://www.zeit.de/online/2008/37/datenschutz-ergebnis, 
abgerufen am 9. Mai 2017) und die Erkenntnis, dass die Verpflichtung der Mitarbeiter auf das 
Datengeheimnis nach $ 5 S. 2 BDSG in vielen Fällen nicht erfolgt (Ehmann in: Simitis, BDSG 
2014, § 5 Rn. 30 ). 
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Um die qualitative Analyse auf eine breitere Basis zu stellen, wurden zusatzlich 
Auskunftsersuchen an Unternehmen versendet, bei denen die beteiligten 
Forscher bereits seit langerem registriert waren. Insgesamt kamen so 40 
Auskunftsersuchen zusammen. Die Auskunftsersuchen wurden zunächst per E- 
Mail gestellt." Wo nötig, insbesondere im Bankensektor, wurde eine postalische 
Anfrage nachgereicht. Hinweise auf die Art der personenbezogenen Daten 
wurden auf Nachfrage bereitwillig gegeben. 


In der erweiterten Stichprobe befanden sich sechs international agierende 
US-amerikanische Unternehmen, die auch auf dem deutschen Markt stark 
vertreten sind. Bei zwei Unternehmen konnte die Herkunft nicht zweifelsfrei 
geklärt werden. Die übrigen 32 Unternehmen stammen aus Deutschland, 
darunter sechs DAX-Konzerne und wesentliche, deutschlandweit vertretene 
Internetzugangs-und Mobilfunkanbieter. Versicherungen, Banken, Handel, 
Logistik, Auskunfteien und viele weitere Branchen waren ebenso vertreten. 
Die Stichprobe ist nicht repräsentativ, bietet aber einen guten Querschnitt durch 
die deutsche Unternehmenslandschaft. 


Die qualitative Prüfung der Auskünfte erfolgte entlang der zwölf in Tabelle A.2 
aufgelisteten Anforderungen. Die Anforderungen wurden aus den Vorgaben 
des Datenschutzrechtes abgeleitet. Details dazu finden sich im Kapitel 3 dieser 
Arbeit. Querreferenzen sind in der Tabelle mitangegeben. 


Die Anforderungen teilen sich in drei formale (# 1-3) und neun inhaltliche 
(# 4-12) Anforderungen auf. Anforderung 1 wurde als erfüllt gewertet, wenn auf 
der Webseite des Unternehmens eine geeignete E-Mailadresse oder Postadresse 
angegeben oder ein Webformular verfügbar war. Die Anforderung wurde 
als teilweise erfüllt angesehen, falls es möglich war, das Unternehmen auf 
irgendeinem anderen Weg zu kontaktieren. Anforderung 2 wurde als erfüllt 
angesehen, falls die Anfrage innerhalb von 28 Tagen (4 Wochen) beantwortet 
wurde. Unternehmen, deren Antworten als teilweise erfüllt angesehen wurden, 
hatten zwar zum Ende des Zeitraums geantwortet, jedoch nur auf mehrfache 


1 Wortlaut: Sehr geehrte Damen und Herren, hiermit mache ich von meinem datenschutzrechtlichen 
Auskunftsrecht Gebrauch. Bitte übersenden Sie mir die vollständige Auskunft per E-Mail oder 
postalisch an [...]. Mit freundlichen Grüßen [...]. 
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Tabelle A.2: Allgemeine Anforderungen an Datenschutzauskünfte 


# Anforderung Kapitel 


Das Recht auf Auskunft muss über die üblichen Kom- 3.3 
munikationskanäle wahrnehmbar sein. 

2 Das Auskunftsersuchen muss innerhalb einer angemes- 3.5 
senen Frist beantwortet werden. 

3 Die Auskunft muss für gewöhnliche Bürger verständlich 3.5 
sein. 

4 Alle von der verantwortlichen Stelle gespeicherten per- 3.7.1 
sonenbezogenen Daten müssen in nicht-abstrakter Wei- 
se aufgeführt werden. 

5 Der Ort der Speicherung (Datei, Datenbank, Stelle, 3.7.1 
Abteilung,...) aller personenbezogenen Daten muss mit- 
geteilt werden. 

6 Die Herkunft aller personenbezogenen Daten muss 3.7.3 
erwähnt werden. 

7 Jede Übermittlung personenbezogener Daten muss an- 3.7.2 
gegeben werden. 

8 Alle Empfänger oder Kategorien von Empfängern per- 3.7.2 
sonenbezogener Daten müssen erwähnt werden. 

9 Die übermittelten personenbezogenen Daten müssen 3.7.2 
aufgelistet werden. 

10 Der interne Fluss personenbezogener Daten muss auf 3.7.2 
nachvollziehbare Weise beauskunftet werden. 

11 Der Zweck der Verarbeitung muss für jedes personen- 3.7.5 
bezogene Datum angegeben werden. 

12 Der Zweck der Erhebung eines personenbezogenen 3.7.5 
Datums muss in jedem Verarbeitungsschritt nachvoll- 
ziehbar sein. 


Nachfrage. Unternehmen, die die Anforderung nicht erfüllt haben, hatten 
auch nach Ablauf der doppelten Zeit noch nicht geantwortet. Im Durchschnitt 
wurden Auskunftsanfragen nach etwa 8 Tagen beantwortet. Anforderung 3 
wurde als erfüllt angesehen, falls keine unverständliche Codierung der Daten 
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Anforderung # 


o uDU RAR WN 


\o 


# Unternehmen 


gs Eıfüllt Teilweise erfüllt E Nicht erfüllt Nicht auswertbar 


Abbildung A.1: Erfüllungsgrad der Anforderungen durch die erteilten Auskünfte 


verwendet wurde. Die Anforderung wurde als teilweise erfüllt gewertet, falls nur 
vereinzelte Angaben unverständlich waren. Die Anforderungen 4-12 wurden als 
erfüllt betrachtet, wenn die jeweiligen Angaben vollständig waren. Sie wurden 
als teilweise erfüllt gewertet, wenn jeweils zumindest ein überwiegender 
Anteil der erforderlichen Angaben vorhanden war. Die Vollständigkeit wurde 
großzügig interpretiert. 


Abbildung A.1 zeigt den Erfüllungsgrad der Anforderungen durch die erteilten 
Auskünfte. Die Situation bei den formalen Kriterien liegt im akzeptablen 
Bereich. Bis auf ein Unternehmen konnten alle auf irgendeine Art und Weise 
kontaktiert werden. 27 Unternehmen (67,5 %) beantworteten die Auskunftsan- 
frage in weniger als 15 Tagen. Nur sechs Unternehmen stellten auch nach 6 
Monaten noch keine Auskunft zur Verfügung. Vier davon waren die verdächti- 
gen Unternehmen aus dem ersten Teil der Studie. Alle Auskünfte bis auf zwei 
waren klar strukturiert und verständlich formuliert. 
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Die Lage bei den inhaltlichen Kriterien fallt deutlich schlechter aus. Insbeson- 
dere Angaben zu Speicherort, Empfängern, Datenflüssen und dem Zweck der 
Speicherung sind unvollständig. Der Speicherort wurde meist dann sichtbar, 
wenn Screenshots von Datenbankanwendungen als Teil der Auskunft mitgelie- 
fert wurden. Dies war immerhin bei sechs Unternehmen der Fall. Die internen 
Flüsse personenbezogener Daten wurden in keinem Fall voll zufriedenstellend 
wiedergegeben. Nur wenige Auskünfte beinhalten überhaupt Angaben dazu. 
Positive Ausnahme war ein deutscher Versand- und Einzelhändler, der grundle- 
gende Informationen zu den an der Datenverarbeitung beteiligten Abteilungen 
mitlieferte. Er stand auch insgesamt mit 11 erfüllten oder teilweise erfüllten 
Anforderungen an der Spitze. 
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B Ableitung datenschutzrechtlicher 
Anforderungen und Kriterien sowie 
technischer Anforderungen an 
Datenschutzauskunftssysteme 


In den nachfolgenden Abschnitten wird die Ableitung der einzelnen daten- 
schutzrechtlichen Anforderungen und Kriterien sowie der technischer Anfor- 
derungen an Datenschutzauskunftssysteme gemäß EVAL (Kapitel 4.1.2) im 
Detail nachvollzogen. Für jeden Teilschritt des Models wird dargelegt, inwie- 
fern die abgeleiteten Anforderungen und Kriterien vollständig sind. Außerdem 
werden Argumente für ihre jeweilige Korrektheit angeführt. 


B.1 Ableitung datenschutzrechtlicher 
Anforderungen 


Als einfachgesetzliche Konkretisierung der rechtlichen Ziele lassen sich die 
rechtlichen Anforderungen aus den maßgeblichen Gedanken der Gesetzgebung 
herleiten. Wesentliche Rechtsgrundlage für den Datenschutz in Deutschland 
ist das BDSG. Deshalb bezieht sich die Analyse auch schwerpunktmäßig auf 
dieses Gesetz. 


An den Stellen, an denen es sinnvoll erscheint wird darüber hinaus auch die 
gegenwärtige und zukünftige europäische Gesetzgebung, insbesondere die 
DSGVO, mit in den Blick genommen. So wird vermieden, dass wichtige 
zukünftige oder internationale Anforderungen außer Acht gelassen werden. 
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An wenigen Punkten werden auch Regelungsvorgaben des Bundesverfassungs- 
gerichts mit in den Blick genommen, die zwar nicht den Weg in die einfachen 
Gesetze gefunden haben, aber in der Gesamtschau der Grundrechte dennoch 
auch für den Datenschutz zu berücksichtigen sind. 


Die Analyse der Vollständigkeit der Anforderungen bezieht sich nur auf 
das Bundesdatenschutzgesetz. Rechtliche Anforderungen sind nicht statisch. 
Ebenso wie die Gesetze selbst unterliegen auch sie einem ständigen Wandel. 
Deshalb kann auch niemals eine absolute Vollständigkeitsaussage getroffen 
werden. 


B.1.1 Synthese - Korrektheit der Anforderungen 


Eine datenschutzrechtliche Anforderung ist dann korrekt, wenn sie sich auf 
eine rechtliche Grundlage stützen kann, diese Rechtsgrundlage zutreffend 
wiedergegeben ist und die Anforderung klar gegenüber anderen Anforderungen 
abgegrenzt ist. Die Tabelle B.1 gibt einen Überblick über die einfachgesetzliche 
Verankerung der datenschutzrechtlichen Anforderungen. In den nachfolgen- 
den Abschnitten wird für jede Anforderung behandelt, inwiefern sie korrekt 
hergeleitet wurde. 


Tabelle B.1: Tabellarische Übersicht der Herkunft datenschutzrechtlicher Anforderungen 


Datenschutzrechtliche Anforderung Einfachgesetzliche Verankerung 

Datenvermeidung $ 3a S. 1 BDSG, Art. 5 Abs. 1 
Lit. c DSGVO 

Datensparsamkeit § 3a S. 1 BDSG, Art. 5 Abs. 1 
Lit.c u. Art. 32 Abs. I Lit. a 
DSGVO 


Anonyme und pseudonyme Dienste $ 13 Abs. 6 u. 7 TMG 
Datenschutzfreundliche Grundeinstel- Art. 25 Abs. 2 DSGVO 
lungen 

Datengeheimnis § 5 BDSG 
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Zutritts- und Zugangskontrolle 


Zugriffs- und Weitergabekontrolle 


Verfiigbarkeitskontrolle 


Datenkorrektheit 


Revisionssichere Protokollierung (Ein- 


gabekontrolle) 
Recht auf Datenübertragbarkeit 
Prinzip der Verantwortlichkeit 


Prinzip der nicht-automatisierten Ein- 


zelentscheidung 
Einwilligung 
Einheitliche Ansprechpartner 


Datenschutzkontrolle durch unabhängi- 


ge BfD 
Meldepflicht 


Aufklärungspflichten 


Hinweis- und Kennzeichnungspflichten 


Unterrichtungspflichten 


Benachrichtigungspflichten 
Auskunftsanspruch 


Vorabkontrolle und Datenschutzfolgen- 


abschätzung 

Datenschutzaudit 
Informationspflichten (bei 
Verletzungen) 


Anlage zu $ 9 S. 1 BDSG 
Nr. 1u.2, Art. 5 Abs. 1 Lit. f 
DSGVO 

Anlage zu $ 9 S. 1 BDSG 
Nr. 3 u. 4, Art. 32 Abs. 1 Lit. b 
DSGVO 

Anlage zu § 9 S. 1 BDSG Nr. 7, 
Art. 32 Abs. 1 Lit.c DSGVO 
Art. 6 Lit. d DSRL, Art. 5 Abs. 1 
Lit. d DSGVO 

Anlage zu § 9 S. 1 BDSG Nr. 5, 
Art. 5 Abs. 1 Lit. f DSGVO 

Art. 20 DSGVO 

Definitorisch in § 3 Abs. 7 BDSG, 
Art. 5 Abs. 2 DSGVO 

§ 6a BDSG, , Art. 22 DSGVO 


§ 4a BDSG, Art. 7 DSGVO 

Art. 26 DSGVO 

§ 4f, §§ 22 ff. BDSG, Art. 39 
DSGVO 

§ 4d Abs. 1 BDSG, Art. 36 
DSGVO 

u.a. § 4a Abs. 1 S.2 BDSG 

u.a. § 6b Abs. 2 BDSG 

§ 4 Abs. 3 S. 1 BDSG, Art. 13 
DSGVO 

§§ 33, 19a BDSG, Art. 14 DSGVO 
§§ 19, 34 BDSG, Art. 15 DSGVO 
§ 4d Abs. 5 BDSG, Art. 35 
DSGVO 

§ 9a BDSG, , Art. 41, 42 DSGVO 
§ 42a BDSG 
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Führung eines Verfahrensverzeichnis- 
ses 

Recht auf Berichtigung 

Recht auf Löschung 

Recht auf Sperrung 
Widerspruchsrecht 


Zweckbestimmung 


Zweckbindung und Zwecktrennung 


Organisatorische und technische Ge- 
waltenteilung 

Grundsatz der Direkterhebung 

Verbot mit Erlaubnisvorbehalt 
Verhältnismäßigkeitsprinzip 


§ 4g Abs. 21. V. m. § 4e S. 1 BDSG 


§§ 20 Abs. 1, 35 Abs. 1 BDSG, 
Art. 16 DSGVO 

§§ 20 Abs. 2, 35 Abs. 2 BDSG, 
Art. 17 DSGVO 

§§ 20 Abs. 3, 35 Abs. 3 BDSG, 
Art. 18 DSGVO 

§ 20 Abs. 5 BDSG, Art. 21 
DSGVO 

Uber das ges. BDSG verteilt; u.a. 
§ 28 Abs. 1 S.2 BDSG 

Uber das ges. BDSG verteilt, tech- 
nisch in der Anlage zu § 9 S. 1 
BDSG Nr. 8, Art. 5 Abs. 1 Lit. b 
DSGVO 

BVerfG, 18.12.1987, 1 BvR 
962/87 = NJW 1988, 959 

§ 4 Abs. 2 S. 1 BDSG 

§ 4 Abs. 1 BDSG, Art. 6 DSGVO 
u.a. § 4 Abs. 2 S. 2 Nr. 2 Lit. a 
BDSG 


Datenvermeidung Die Datenvermeidung findet sich wörtlich in § 3a S. 1 
BDSG. Sie fordert, dass nur Daten erhoben werden, die für den jeweiligen 
definierten Zweck tatsächlich benötigt werden. Die Datenvermeidung führt 
zum höchsten Datenschutzniveau, da nur von Daten, die tatsächlich erhoben 
werden, eine Gefährdung für das Recht auf informationelle Selbstbestimmung 
ausgehen kann. 


Datensparsamkeit Die Datensparsamkeit ist, wie die Datenvermeidung, in 
$ 3a S. 1 BDSG enthalten. Im Gegensatz zur Datenvermeidung stellt die 
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Datensparsamkeit keine Anforderungen an die Erhebung, sondern an die 
Verarbeitung und Nutzung personenbezogener Daten. Sie gibt vor, dass für 
jeden einzelnen Verarbeitungsvorgang nur diejenigen Daten verwendet werden 
sollen, die für den jeweiligen Zweck erforderlich sind. 


In Konkretisierung wird in $ 3a S. 2 BDSG erwähnt, dass dies auch bedeutet, 
dass personenbezogene Daten vor dem Eingang in ein Datenverarbeitungver- 
fahren soweit möglich zu anonymisieren oder zu pseudonymisieren sind. 


Anonyme und pseudonyme Dienste Der Vollständigkeit halber ist die An- 
forderung der Bereitstellung anonymer und pseudonymer Dienste aufgeführt. 
Diese ist keine Anforderung des BDSG, sondern eine des $ 13 Abs. 6 u. 7 
TMG. Sie bezieht sich auf eine Kommunikationsbeziehung zwischen einem 
(potentiell) Betroffenen und der verantwortlichen Stelle und wirkt bereits 
zum Erhebungszeitpunkt. Insofern handelt es sich um eine für Telemedien 
spezifische Regelung der Datenvermeidung. 


Datenschutzfreundliche Grundeinstellungen Datenschutzfreundliche 
Grundeinstellungen sind im BDSG nicht explizit als Anforderung enthalten, 
entsprechen jedoch bereits heute dem Geist der Datenvermeidung und der 
Zweckbindung. Explizit aufgeführt sind sie in Art. 25 Abs. 2 DSGVO. 
Datenschutzfreundliche Grundeinstellungen müssen im Hinblick auf die Menge 
der erhobenen personenbezogenen Daten, den Umfang ihrer Verarbeitung, ihre 
Speicherdauer und ihre Zugänglichkeit für Dritte gewählt werden. 


Datenschutzfreundliche Grundeinstellungen beziehen sich nicht ausschließlich 
auf die Verarbeitungsvorgänge bei der verantwortlichen Stelle. Als Teil des 
Datenschutzes durch Technikgestaltung sind sie beim Entwurf von Software 
und und beim Design von Benutzeroberflächen mitzuberücksichtigen (ErwGr 
78 DSGVO). Datenschutzfreundliche Grundeinstellungen stehen in Beziehung 
zur Einwilligung indem sie die Zahl der explizit erforderlichen Einwilligungen 
erhöhen. 
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Datengeheimnis Das Datengeheimnis des $ 5 BDSG ist eine organisatori- 
sche Anforderung. Es richtet sich an das mit der Datenverarbeitung betraute 
Personal und statuiert ein unmittelbares, persönliches, gesetzliches Verbot der 
zweckfremden Verwendung personenbezogener Daten. Die formelle Verpflich- 
tung auf das Datengeheimnis führt zu einer rechtlich stärkeren Bindung mit 
entsprechenden Sanktionen. 


Zutritts- und Zugangskontrolle Die Forderung nach Zutritts- und Zugangs- 
kontrolle vereint die physische Absicherung von Datenverabeitungsanlagen. 
Sie ist in der Anlage zu § 9 S. 1 BDSG Nr. 1 u. 2 verankert. Die Zutritts- 
kontrolle verhindert den physischen Zugang zu Räumlichkeiten, in denen 
Datenverarbeitungsanlagen stehen. Zugangskontrolle verhindert die Nutzung 
von Datenverabeitungssystemen durch Unbefugte mit hard- und softwaretech- 
nischen Mitteln. 


Zugriffs- und Weitergabekontrolle Die Zugriffs- und Weitergabekontrolle 
stellt Anforderungen an das Rechtemanagement (engl. Access Control) in einer 
Datenverarbeitungsanlage. Sie ist in der Anlage zu § 9 S. 1 BDSG Nr. 3 u. 4 
kodifiziert. Die Zugriffskontrolle reglementiert den Zugriff auf personenbezo- 
gene Daten im Zuge eines zweck- und rollenadäquaten Rechtemanagements. 
Die Weitergabekontrolle verlangt, dass personenbezogene Daten, auf die eine 
Person Zugriff hat, von dieser nur tibermittelt oder weitergegeben werden 
können, wenn dies datenschutzrechtlich zulässig ist. 


Verfügbarkeitskontrolle Die Verfügbarkeitskontrolle in der Anlage zu $ 9 
S. 1 BDSG Nr. 7 verlangt, dass personenbezogene Daten gegen zufällige 
Zerstörung oder Verlust geschützt werden. Sie ist der speicherseitige Aspekt 
des Verfügbarkeitsziels. 


Datenkorrektheit Die Datenkorrektheit hat eine große inhaltliche Nähe zum 
Recht auf Berichtigung. Ob sie deshalb als eigene Anforderung gelten kann, ist 
fraglich. Erwähnt wird sie in Art. 6 Lit. d DSRL und nicht im BDSG selbst. Für 


350 


B.1 Ableitung datenschutzrechtlicher Anforderungen 


die Aufnahme als eigene Anforderung spricht, dass die Datenkorrektheit, im 
Gegensatz zum Recht auf Berichtigung, präventiv wirken soll. Deshalb wurde 
sie in den Anforderungskatalog übernommen. 


Revisionssichere Protokollierung (Eingabekontrolle) Die revisionssichere 
Protokollierung! oder Eingabekontrolle, wie sie in der Anlage zu § 9 S. 1 BDSG 
Nr. 5 genannt wird, ist Teil des Integritätsschutzes. Sie fordert die Nachvoll- 
ziehbarkeit der Erhebung, Modifikation und Löschung von personenbezogenen 
Daten. 


Recht auf Datenübertragbarkeit Das Recht auf Datenübertragbarkeit, wie 
es in Art. 20 DSGVO dargelegt wird, ist keine traditionelle Datenschutzanfor- 
derung. Sie geht in ihrem Charakter eher auf das Wettbewerbsrecht zurück und 
soll den Wechsel des digitalen Dienstleisters ermöglichen, indem Kompatibi- 
lität und Exportmöglichkeiten gefordert werden. Weitere Ausführungen zum 
Recht auf Datenübertragbarkeit finden sich in Kapitel 10.2. 


Prinzip der Verantwortlichkeit Das Prinzip der Verantwortlichkeit manifes- 
tiert sich im BDSG in der verantwortlichen Stelle. Definitorisch findet es sich 
in $ 3 Abs. 7 BDSG, ist aber letztendlich über das gesamte Datenschutzrecht 
verteilt. Verantwortlichkeit heißt, dass nur dort eine Verarbeitung personenbe- 
zogener Daten stattfinden darf, wo geklärt ist, welche Stelle die Verantwortung 
dafür trägt. Das Prinzip wirkt auch in die interne organisatorische Ausge- 
staltung des Betriebs eines Datenverarbeitungssystems hinein. Dazu zählt, 
dass Rechte, Befugnisse und Entscheidungsgewalt im gleichen Schritt mit der 
Verantwortung vergeben werden. 


Prinzip der nicht-automatisierten Einzelentscheidung Um den Betroffenen 
nicht zum Objekt der Datenverarbeitung werden zu lassen und um zu verhindern, 
dass Maschinen Menschen kontrollieren, darf nach $ 6a Abs. 1 S. 1 BDSG 


! BVerfGE 125, 260 (325 f.). 
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jede Entscheidung, die den Betroffenen erheblich beeinträchtigt, grundsätzlich 
nicht ausschließlich auf eine automatisierte Verarbeitung gestützt werden. 


Einwilligung Neben Rechtsvorschriften kann nach $ 4 Abs. 1 BDSG nur die 
Einwilligung nach $ 4a BDSG zur Zulässigkeit eines Umgangs mit personenbe- 
zogenen Daten führen. Die Anforderung der Einwilligung mündet darin, dass 
für jede Datenerhebung, -verarbeitung und -nutzung eine Einwilligung beim 
Betroffenen einzuholen ist, soweit keine andere Rechtsgrundlage existiert. 


Einheitliche Ansprechpartner Die Forderung nach einem einheitlichen An- 
sprechpartner (engl. Single Point of Contact - SPOC) ist nicht Teil des BDSG. 
Bei gemeinsam für eine Verarbeitung Verantwortlichen sieht Art. 26 Abs. 1 
DSGVO vor, dass die Verantwortlichen eine Vereinbarung darüber schließen, 
welche Stelle welche datenschutzrechtlichen Verpflichtungen erfüllt. Eine 
Vereinbarung über eine einheitliche Auskunft soll den Betroffenen darin un- 
terstützen, sein Auskunftsrecht bei dem Ansprechpartner geltend zu machen, 
bei dem er seine Rechte am effektivsten und effizientesten wahrnehmen kann. 
Die Vereinbarung ist für den Betroffenen jedoch nicht bindend (siehe Kapitel 
3.3). Art. 26 Abs. 3 DSGVO sieht, wie bereits $ 6 Abs. 2 S. 2 BDSG, vor, 
dass der Betroffene seine Rechte gegenüber jedem Beteiligten geltend machen 
kann. ErwGr 59 sieht gemeinsam mit Art. 12 Abs. 1 DSGVO vor, Anträge 
elektronisch zu stellen. Deren Beantwortung sollte nach ErwGr 63 idealerweise 
direkt per Zugriff auf eine elektronische Plattform erfolgen. 


Datenschutzkontrolle durch unabhängige BfD Die Datenschutzkontrolle 
durch unabhängige BfD ist für öffentliche und nicht-öffentliche Stellen, die 
personenbezogene Daten verarbeiten, in $ 4f BDSG festgelegt. Der aufsichts- 
rechtliche Gegenpart sind der Bundesbeauftragte für den Datenschutz und 
die Informationsfreiheit (BfDI, $$ 22 ff. BDSG) und die Aufsichtsbehörden 
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der Länder (§ 38 BDSG). Die Unabhängigkeit all dieser Institutionen wurde 
unlängst durch den EuGH gestärkt. ! 


Meldepflicht Hat eine verantwortliche Stelle keinen BfD berufen, unterliegt 
sie der Meldepflicht nach $ 4d Abs. 1 BDSG. Sie muss, bis auf Ausnahmen, 
alle Verfahren der automatisierten Datenverarbeitung vor ihrer Inbetriebnahme 
bei der Aufsichtsbehörde bzw. dem übergeordneten Beauftragten für den 
Datenschutz melden. 


Aufklärungspflichten Aufklärungspflichten,” wie sie unter anderem in § 4a 
Abs. 1 S. 2 BDSG für die Einwilligung festgelegt sind, sollen sicherstellen, dass 
dem Betroffenen die Konsequenzen seines Handelns oder des Handelns der 
verantwortlichen Stelle deutlich gemacht werden. Im Gegensatz zu Hinweisen 
und Kennzeichnungen sind sie immer direkt an einen bestimmten Betroffenen 
gerichtet. Die Unterrichtung folgt, anders als die Aufklärung, der Erhebung 
nach. 


Hinweis- und Kennzeichnungspflichten, Unterrichtungspflichten, Benach- 
richtigungspflichten und Auskunftsanspruch Die der Erhebung personen- 
bezogener Daten nachgelagerten Transparenzpflichten wurden bereits im Ka- 
pitel 3.1 beschrieben und gegeneinander abgegrenzt. 


Vorabkontrolle und Datenschutzfolgenabschätzung Die Vorabprüfung au- 
tomatisierter Verarbeitungsanlagen, die besondere Risiken und Gefährdungen 
für den Betroffenen in sich tragen, ist in § 4d Abs. 5 BDSG festgelegt. Die 
Vorabkontrolle wird vom BfD durchgeführt und ist im Allgemeinen organi- 
satorischer Natur. Auf europäischer Ebene ist in Art. 35 DSGVO eine noch 
weitergehende Datenschutzfolgenabschätzung enthalten, die den gesamten 
Entwicklungsprozess einer Datenverarbeitungsanlage betrifft. 


l! EuGH, NJW 2010, 1265 (1265). 
2 Siehe auch BVerfGE 65, 1 (46). 
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Datenschutzaudit Ein Datenschutzaudit als Transparenzmaßnahme ist in 
§ 9a BDSG verankert. Kriterien für ein Datenschutzaudit sollten in ein eigenes 
Gesetz eingehen,! das aber nie verwirklicht wurde. 


Informationspflichten (bei DS-Verletzungen) Jenseits der allgemeinen 
Transparenzanforderungen statuiert $ 42a BDSG eine weitergehende Informa- 
tionspflicht bei unrechtmäßiger Kenntniserlangung personenbezogener Daten 
durch Dritte. 


Führung eines Verfahrensverzeichnisses Der BfD der verantwortlichen 
Stelle hat nach § 4g Abs. 2 i. V.m. § 4e S. 1 BDSG ein Verfahrensverzeichnis, 
im Umfang den meldepflichtigen Angaben ähnlich, zu führen und jedermann 
verfügbar zu machen. 


Recht auf Berichtigung Nach den $$ 20 Abs. 1, 35 Abs. 1 BDSG sind 
diejenigen personenbezogenen Daten, die unrichtig sind, zu berichtigen. Im 
Regelfall geschieht dies auf Antrag des Betroffenen, nachdem er aufgrund 
seines Auskunftsrechts Einblick in seine personenbezogenen Daten erhalten 
hat. Das Recht auf Berichtigung ist somit das erste der drei universellen 
Interventionsrechte. 


Recht auf Löschung Das zweite wesentliche Interventionsrecht ist das Recht 
auf Löschung. Demgemäß sind, entsprechend der $$ 20 Abs. 2, 35 Abs. 2 
BDSG, diejenigen personenbezogenen Daten, die für einen bestimmten Zweck 
nicht mehr erforderlich sind, zu löschen. Die Löschung kann auf Antrag des 
Betroffenen erfolgen, kann aber auch intern durch wohldefinierte Löschregeln 
ausgelöst werden. 


! BT-Drs. 16/12011. 
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Recht auf Sperrung Ist eine Löschung nicht möglich, tritt an ihre Stelle die 
Sperrung nach $$ 20 Abs. 3, 35 Abs. 3 BDSG. Eine Sperrung bedeutet, dass 
die Daten so gekennzeichnet werden, dass ihre Verarbeitung und Nutzung 
weitestmöglich eingeschränkt werden ($ 3 Abs. 4 Nr. 4 BDSG). 


Widerspruchsrecht Das Widerspruchsrecht ist eine Sonderregelung für öf- 
fentliche Stellen und entstammt dem Verwaltungsverfahrensrecht. Es ist in 
$ 20 Abs. 5 BDSG für das Datenschutzrecht übernommen worden. 


Zweckbestimmung Die Zweckbestimmung ist als Kernforderung des Daten- 
schutzes über das gesamte BDSG verteilt. Für die Erhebung personenbezogener 
Daten zu eigenen Geschäftszwecken findet sich die Forderung beispielsweise 
in § 28 Abs. 1S.2 BDSG. Weitere Ausführungen finden sich im Kapitel 3.7.5. 


Zweckbindung und Zwecktrennung Ebenso wie die Zweckbestimmung sind 
auch Zweckbindung und Zwecktrennung über das gesamte BDSG verteilt. 
Die Zweckbindung fordert, dass personenbezogene Daten nur zu dem Zweck 
verarbeitet und genutzt werden dürfen, zu dem sie erhoben wurden und der für 
sie dokumentiert wurde. Unter vielen findet sich diese Festlegung beispielsweise 
in $ 28 Abs. 3 S. 7 BDSG. 


Die Zwecktrennung ist Ausfluss eines wesentlichen Aspekts der Unverkettbar- 
keit. Personenbezogene Daten, die zu unterschiedlichen Zwecken verarbeitet, 
insbesondere gespeichert werden, dürfen nicht zusammengeführt werden. Mit 
technischem Bezug ist dies in der Anlage zu § 9 S. 1 BDSG Nr. 8 festgelegt. 


Organisatorische und technische Gewaltenteilung Die organisatorische 
und technische Gewaltenteilung im Rahmen der informationellen Gewalten- 
teilung folgt aus dem Gebot der Zweckbindung und Zwecktrennung. Ihr liegt 
das verwaltungsrechtliche Abschottungsprinzip zugrunde. Die informationelle 
Gewaltenteilung ist nicht im BDSG festgelegt, sondern ergibt sich aus der 
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Rechtsprechung des Bundesverfassungsgerichts,! in dessen Lichte das BDSG 
auszulegen ist. 


Während sich Zweckbindung und Zwecktrennung auf die personenbezogenen 
Daten selbst beziehen, ist die informationelle Gewaltenteilung eine Forderung, 
die direkt an die organisatorischen und technischen Einrichtungen gestellt 
wird. Die Zwecktrennung untersagt die Zusammenführung personenbezogener 
Daten. Die Gewaltenteilung verpflichtet dazu, dass Zugriffsrechte, Rollen 
sowie physische und logische Speicherorte nicht beliebig festgelegt werden. 
Sie sind entsprechend dem Zweck und nach dem Prinzip der Machtdistribution 
festzulegen. 


Grundsatz der Direkterhebung Der Grundsatz der Direkterhebung ist in $ 4 
Abs. 2 S. 1 BDSG festgelegt. Er stärkt die Einflussnahme und Selbstbestimmung 
des Betroffenen bei der Erhebung personenbezogener Daten. 


Verbot mit Erlaubnisvorbehalt Das Verbot mit Erlaubnisvorbehalt des Da- 
tenschutzes kann für nicht-Öffentliche Stellen nicht aus den Grundrechten 
abgeleitet werden, sondern ist eine rechtspolitische Entscheidung des Gesetz- 
gebers.” Diese Grundsätzliche Forderung findet sich prominent in $ 4 Abs. 1 
BDSG. 


Verhältnismäßigkeitsprinzip Das Verhältnismäßigkeitsprinzip ist nicht aus 
Datenschutzgrundrechten abgeleitet, sondern Teil des Rechtsstaatsprinzips in 
Art. 20 Abs. 2 GG.? Es findet sich in den Vorschriften des BDSG unter anderem 
in § 4 Abs. 2 S. 2 Nr. 2 Lit. a BDSG, ist jedoch ein grundsätzliches Prinzip, das 
sich tiber das gesamte deutsche Recht und damit auch das Datenschutzrecht 
erstreckt. 


! BVerfGE 65, 1 (69); BVerfG, NJW 1988, 959 (961). 
2 Rudolf in: Merten/Papier, HGR IV 2011, § 90 Rn. 28. 
3 BVerfGE 19, 342 (348 f.). 
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B.1.2 Vollständigkeit in Bezug auf das BDSG 


Die Vollständigkeit der Anforderungen in Bezug auf das BDSG kann nicht 
im formalen Sinne bewiesen werden. Dennoch soll durch eine kursive Ge- 
samtschau auf das BDSG deutlich gemacht werden, dass dessen wesentliche 
Anforderungen in Tabelle B.1 enthalten sind und keine Vorschrift in der 
Analyse unberücksichtigt blieb. 


Das BDSG ist in sechs Abschnitte unterteilt. Der erste Abschnitt ($$ 1 bis 11) 
umfasst allgemeine Bestimmungen und Definitionen, die sowohl für öffentliche, 
als auch für nicht-öffentliche Stellen gelten. Der zweite Abschnitt ($$ 12 bis 
26) widmet sich der Datenverarbeitung der öffentlichen Stellen, während der 
dritte Abschnitt (§§ 27 bis 38a) die Datenverarbeitung nicht-öffentlicher Stellen 
in den Blick nimmt. 


Die Abschnitte vier ($$ 39 bis 42a), fünf (§§ 43 und 44) und sechs (§§ 45 
bis 48) beinhalten Sondervorschriften, Schlussvorschriften und Übergangs- 
vorschriften. In ihnen finden sich keine allgemeingültigen Anforderungen. 
Sonderregularien wie die Gegendarstellung im Medienrecht ($ 41 Abs. 2) 
bleiben im Folgenden unberücksichtigt. Einzig die aufgenommenen Informati- 
onspflichten bei unrechtmäßiger Kenntniserlangung von Daten des $ 42a haben 
allgemeine Bedeutung. 


Die Abschnitte 2 und 3 sind jeweils noch einmal in drei Unterabschnitte 
unterteilt. Sie befassen sich jeweils mit den eigentlichen Rechtsgrundlagen 
der Datenverarbeitung, den Rechten des Betroffenen und dem BfDI bzw. der 
Aufsichtsbehörde. Der letzte Unterabschnitt wird insgesamt durch die auch 
betrieblich beziehungsweise behördlich geltende Forderung nach unabhängigen 
Datenschutzbeauftragten miterfasst, sind ansonsten jedoch von keiner weiterge- 
henden Relevanz für die Erhebung der datenschutzrechtlichen Anforderungen 
für den Einsatz von Datenverarbeitungsanlagen. 


Die $$ 1 bis 3 beschreiben den Anwendungsbereich des Gesetzes und enthal- 
ten Definitionen und Begriffsbestimmungen. Aus diesen ergeben sich keine 
Anforderungen, sie tragen jedoch zum Verständnis sich an anderer Stelle 
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ergebender Anforderungen bei. Die Anforderungen der $$ 3a (Datenver- 
meidung und Datensparsamkeit), 4 (Grundsatz der Direkterhebung, Verbot 
mit Erlaubnisvorbehalt und Unterrichtungspflichten sowie beispielhaft das 
Verhältnismäßigkeitsprinzip) sowie 4a (Einwilligung und beispielhaft die 
dazugehörigen Aufklärungspflichten) wurden in der Anforderungsanalyse be- 
rücksichtigt (siehe Tabelle B.1). Die Auslandsübermittlung in den $ 4b und 4c 
steht als Spezialregelung außerhalb des Betrachtungsumfangs dieser Analyse. 
Sie stellen organisatorisch-rechtliche Anforderungen, die zu erfüllen sind, 
bevor eine Übermittlung stattfindet. Die Meldepflicht ($$ 4d und 4e) sowie die 
Bestellung eines BfD (§§ 4f und 4g) sind berücksichtigt. Die Vorabkontrolle 
und die Führung eines Verfahrensverzeichnisses als besondere Aufgaben des 
BfD wurden gesondert erfasst. Das Datengeheimnis des $ 5 ist ebenfalls in der 
Liste der extrahierten Anforderungen enthalten. 


$ 6, der die Rechte des Betroffenen beschreibt, greift dem zweiten Unter- 
abschnitt der Abschnitte 2 und 3 vor. Es finden sich an dieser Stelle keine 
eigenen Anforderungen, sondern nur Kriterien für die Ausgestaltung der An- 
forderungen des zweiten Unterabschnitts. Der nachfolgende $ 6a statuiert das 
Prinzip der nicht-automatisierten Einzelentscheidung und erweitert in Absatz 
3 den Kriterienkatalog des Auskunftsanspruchs um den logischen Aufbau der 
automatisierten Verarbeitung. Ersteres ist berücksichtigt, letzteres findet sich 
auf der nächsten Ebene des EVAL-Modells wieder. Für die Videoüberwachung 
enthält $ 6b besondere Kriterien für die einzelnen datenschutzrechtlichen 
Anforderungen, insbesondere die Betroffenenrechte. Eine Besonderheit ist die 
Hinweis- und Kennzeichnungspflicht, weshalb diese als eigene Anforderung 
übernommen wurde. Mobile personenbezogene Speicher- und Verarbeitungs- 
medien unterliegen der besonderen Unterrichtungspflicht des $ 6c, die bereits 
durch $ 4 in den Anforderungskatalog aufgenommen wurde. 


Die $$ 7 und 8 beschäftigen sich mit dem Schadenersatz und stehen eher 
im Kontext des vierten und fünften Abschnitts. Sie enthalten keine eigenen 
Anforderungen, die auf technische oder organisatorische Vorgänge übertragbar 
wären. Demgegenüber eröffnet $ 9 gleich einen ganzen Katalog von Anfor- 
derungen, die als technisch-organisatorische Maßnahmen bezeichnet werden. 
Sie finden sich gesammelt in einem Anhang des BDSG. Im Detail handelt 
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es sich um die Zutritts- und Zugangskontrolle, die Zugriffs- und Weitergabe- 
kontrolle, die Eingabekontrolle als Teil der revisionssicheren Protokollierung, 
die Verfiigbarkeitskontrolle und die Zwecktrennung. Die Auftragskontrolle 
ist Teil des Verantwortlichkeitsprinzips und wurde deshalb nicht als eigene 
Anforderung erfasst. Der § 9a bringt das Datenschutzaudit mit in die Liste der 
Anforderungen ein. § 10 listet besondere Kriterien hinsichtlich automatisierter 
Abrufverfahren auf, die sich insbesondere auf die Nachpriifbarkeit im Audit- 
verfahren beziehen. § 11 ergänzt eine Reihe von Dokumentationspflichten und 
Verfahrensanweisungen für die Auftragsdatenverarbeitung. Diese wurden bei 
der durchgeführten Analyse explizit außen vor gelassen. 


Ab dem $ 12 folgen die Abschnitte 2 und 3. In ihrem ersten Unterabschnitt finden 
sich jeweils detaillierte Regelungen für die Zulässigkeit der Datenverarbeitung, 
die Zweckbestimmung und die Zweckbindung. Diese Regelungen spiegeln sich 
im anwendungsspezifischen Kriterienkatalog wider. Einzelne Anforderungen, 
die über das bisher erwähnte hinausgehen, lassen sich jedoch nicht lokalisieren. 
Die Vielfalt der Regelungen beruht vor allem auf dem Prinzip des Verbots mit 
Erlaubnisvorbehalt, das die Auflistung aller Erlaubnistatbestände erforderlich 
macht. 


Wesentliche Anforderungen finden sich im zweiten Unterabschnitt mit den 
Rechten des Betroffenen. Dies sind die Benachrichtigung ($$ 33, 19a), der 
Auskunftsanspruch ($$ 19, 34), das Recht auf Berichtigung ($$ 20 Abs. 1, 
35 Abs. 1), das Recht auf Löschung ($$ 20 Abs. 2, 35 Abs. 2) und das Recht 
auf Sperrung ($$ 20 Abs. 3, 35 Abs. 3). Ergänzend findet sich im zweiten 
Abschnitt auch noch das Widerspruchsrecht (§ 20 Abs. 5). 


Dieser Gesamtüberblick über das BDSG gibt einen Anhaltspunkt für die 
Vollständigkeit der erhobenen Anforderungen. 
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B.2 Ableitung datenschutzrechtlicher Kriterien 


Die Ableitung datenschutzrechtlicher Kriterien wurde im wesentlichen in 
Kapitel 3 behandelt. Deshalb finden sich in diesem Abschnitt vor allem 
Ergänzungen, die über das Kernthema des Auskunftsrechts hinausgehen. 


B.2.1 Korrektheit der datenschutzrechtlichen Kriterien 


Die datenschutzrechtlichen Kriterien sind korrekt, wenn sie methodisch sauber 
aus den Rechtsgrundlagen und ihrer Interpretation abgeleitet wurden. Kapitel 3 
sollte dieser Anforderung genügen. In der Auflistung der Kriterien in Abschnitt 
4.3.1 wird auf die jeweils einschlägigen Argumentationsstränge verwiesen. 


Für die ergänzenden Kriterien des Abschnitts 4.3.2 wurde nicht überall eine 
so umfangreiche Diskussion unternommen. Sie gehen über das Kernthema 
dieser Arbeit hinaus. Dennoch sollen im Folgenden Hinweise gegeben werden, 
weshalb die dargestellten Kriterien dennoch korrekt sind. 


Datenvermeidung Die Kriterien 40 und 41 übertragen das allgemeine Prin- 
zip der Datenvermeidung auf die Protokolldaten und die zugrundeliegenden 
Basisdaten. Die Kriterien 43 und 44 konkretisieren, dass bei der Protokollierung 
keine Daten erhoben werden dürfen, die zur Überwachung von Beschäftigten 
dienen könnten. Sie greifen Kriterien auf, die sich aus der Verbindung des $ 32 
Abs. 1 BDSG mit dem Prinzip der Datenvermeidung ergeben. 


Datensparsamkeit Die Kriterien 45, 46 und 47 regulieren die frühzeitige 
Löschung unterschiedlicher Protokolldaten nach dem Prinzip der Datenspar- 
samkeit. Sie stehen in Beziehung zu den $$ 20 Abs. 2 und 35 Abs. 2 BDSG. 
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Zugriffs-, Zugangs- und Weitergabekontrolle Ein Zugriff Dritter auf perso- 
nenbezogene Protokolldaten ist nach $ 3 Abs. Nr. 3 BDSG eine Übermittlung. 
Bei einem automatisierten Auskunftsverfahren wäre darüber hinaus auch noch 
$ 10 BDSG zu berücksichtigen. In jedem Fall untersagt $ 34 Abs. 5 BDSG 
Ubermittlungszwecke und ohne zulässigen Zweck kann es nach § 4 Abs. 1 
BDSG auch keine zulässige Übermittlung geben. Dies ist in Kriterium 52 
festgehalten. Kriterium 53 führt mit dem 4-Augen-Prinzip ein bewährtes Mittel 
der datenschutzorganisatorischen Kontrolle ein. 


Verfügbarkeitskontrolle Das Kriterium 57 ergibt sich wie die Kriterien 56 
und 60 aus dem Anspruch einer vollständigen und korrekten Auskunft (siehe 
Abschnitt 3.5). Das Kriterium präzisiert diesen Anspruch für das vorgelagerte 
Rechtemanagement. 


Revisionssichere Protokollierung Die Kriterien 58 und 59 sichern die Inte- 
grität der Protokolldaten zu. Auch sie ergeben sich indirekt aus dem Anspruch 
einer vollständigen und korrekten Auskunft. 


Einheitliche Ansprechpartner Kriterium 62 geht auf Art. 12 i. V.m. Art. 
26 DSGVO unter Berücksichtigung der Erwägungsgründe 59 und 63 zurück. 
Nach heutiger Rechtslage sind verbundene verantwortliche Stellen und daraus 
abgeleitete gemeinsame Ansprechpartner noch nicht möglich, eine zentrale 
Plattform noch nicht erforderlich. 


Zweckbindung und Zwecktrennung Das Kriterium 65 geht wie Kriterium 
67 fast wortwörtlich auf $ 34 Abs. 5 BDSG zurück. Kriterium 66 ergibt sich 
aus $ 6 Abs. 31. V.m. $ 31 BDSG. Die Kriterien 68 und 69 konkretisieren die 
Zwecktrennung für die Speicherung und die Verarbeitungsprozesse und gehen 
auf die Anlage zu § 9 S. 1 BDSG Nr. 8 zurück. Protokolldaten und Basisdaten 
haben immer einen unterschiedlichen Zweck und sind deshalb auch in jedem 
Fall zu trennen. 
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Organisatorische und technische Gewaltenteilung Die organisatorische 
und technische Gewaltenteilung findet sich bisher noch kaum in expliziten 
Regelungsvorgaben des Bundesdatenschutzgesetzes. Sie ergibt sich jedoch 
indirekt aus anderen Anforderungen und Kriterien. Das Kriterium 70 ergibt 
sich aus Datensparsamkeit und informationeller Gewaltenteilung. Es lässt sich 
auf die Beschränkung der Nutzung auf die Auskunftszwecke in $ 28 Abs. 1 
i. V.m. § 34 Abs. 5 BDSG zurückführen. Kriterium 71 ist eine weitergehende 
Konsequenz und technische Konkretisierung des Kriteriums 70. Daten, die nicht 
übermittelt werden dürfen, da dies nicht zwingend erforderlich ist, müssen lokal 
beziehungsweise dezentral gespeichert und verarbeitet werden. Die Kriterien 
72 und 73 sind eine explizite Formulierung des Unverkettbarkeitsprinzips, 
angewendet auf die Situation in einem Datenschutzauskunftssystem. 


B.2.2 Vollständigkeit der datenschutzrechtlichen Kriterien 


Die datenschutzrechtlichen Kriterien erheben keinen allgemeinen Anspruch 
auf Vollständigkeit. Einzig die aus dem Auskunftsanspruch abgeleiteten Kri- 
terien sollten in der Gesamtschau alle wesentlichen Aspekte abdecken. Die 
Diskussion des Auskunftsanspruchs im Kapitel 3 ist dahingehend abschlie- 
Bend. Der Vergleich mit der Kommentarliteratur lässt keine Lücken in den 
anwendungsunabhängigen Erwägungen erkennen. Die für ein Datenschutzaus- 
kunftssystem spezifischen Kriterien sind neu und bisher ohne Präzedenzfall. 
Eine Vollständigkeit lässt sich deshalb nicht belegen. 


B.3 Ableitung technischer Anforderungen 


Die technischen Anforderungen leiten sich aus den rechtlichen Kriterien ab. 
Sie stehen in einem N:M-Verhältnis, weshalb manche rechtlichen Kriterien 
von mehreren technischen Anforderungen gemeinsam umgesetzt werden (siehe 
Tabelle 4.2) und andererseits auch bestimmte Anforderungen eine Reihe 
rechtlicher Kriterien vereinen (siehe Tabelle B.2). 
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Die Korrektheit einer technischen Anforderung ergibt sich, wenn sie sich 


vollständig durch die zugrundeliegenden rechtlichen Kriterien erklären lässt. 


Gehen technische Anforderungen über rechtliche Kriterien hinaus, muss dies 
technisch begründet sein und darf nicht im Widerspruch zu rechtlichen Kriterien 


stehen. 


Die Menge der technischen Anforderungen ist vollständig, wenn alle rechtlichen 
Kriterien von ihnen vollständig erfasst werden. 


Tabelle B.2: Technische Anforderungen, die mehrere rechtliche Kriterien umsetzen 


Technische Anforderung Rechtliche Kriterien 


40, 41, 43, 44 
1,58 

1, 2, 3, 13, 24, 31, 64 
1, 15, 19, 21, 28, 29, 31 
1, 20, 28, 29, 42 

1, 14, 17, 28, 29, 32 

1, 12, 28, 29, 32, 44 

1, 8, 11, 27, 28, 29 


30, 68, 69 
6, 57 

6, 25, 26 

6, 22, 23, 25 
6, 46 

6, 47 

21,99 

65, 66, 67 

2, 56, 60 

18, 62 
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B.3.1 Korrektheit der technischen Anforderungen 


Die Korrektheit von Anforderungen, die sich aus genau einem Kriterium erge- 
ben, lässt sich durch einen direkten Vergleich nachvollziehen. Hauptunterschied 
zwischen den rechtlichen Kriterien und den technischen Anforderungen ist bei 
einem solchen 1:1-Verhältnis der technische Bezug. 


Beispielhaft sei dies an der technischen Anforderung 1 dargestellt. Sie fordert 
die Einbettung von Event-Listenern in allen Systemkomponenten, die per- 
sonenbezogene Daten verarbeiten. Diese technische Anforderung lässt sich 
auf das Kriterium 1 zurückführen. Dieses fordert eine Protokollierung aller 
Erhebungs-, Verarbeitungs-, Nutzungs- und Übermittlungsvorgänge. Ohne 
Event-Listener in allen Systemkomponenten ist dieses Kriterium nicht zu 
erreichen, da sonst bestimmte Vorgänge nicht erfasst werden können. Deshalb 
ist die Anforderung 1 korrekt aus dem Kriterium 1 abgeleitet. 


Weitaus interessanter sind diejenigen Anforderungen, die mehrere Kriterien 
umsetzen (siehe Tabelle B.2). Da sich ihre Korrektheit aus dem vollständigen 
Enthaltensein in der Vereinigung der Kriterien ergibt, ist eine genauere Analyse 
notwendig. Diese wird im Folgenden vorgenommen. 


Anforderung 5 Die technische Anforderung 5 vereint die Kriterien der 
Datenvermeidung 40, 41, 43 und 44. Während bei den rechtlichen Kriterien 
einzelne Datenarten aufgelistet werden, die nicht erhoben werden dürfen, geht 
die technische Anforderung den umgekehrten Weg. Sie schreibt fest, dass keine 
Informationen protokolliert werden dürfen, deren Protokollierung nicht speziell 
in einer anderen Anforderung vorgeschrieben ist. Da keine der technischen 
Anforderungen eine Protokollierung der in den Kriterien 40 bis 44 genannten 
Datenarten vorsieht und Kriterium 40 alle Informationen umfasst, die nicht 
Teil des Auskunftsanspruchs sind, ist die Anforderung korrekt umgesetzt. 


Anforderung 6 Das Kriterium 58 ist fast 1:1 in die Anforderung 6 übergegan- 
gen. Dem Kriterium der Nachvollziehbarkeit wird durch den Verweis auf die 
nachfolgenden Anforderungen Genüge getan. Umgekehrt wurde Anforderung 6 
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dahingehend erweitert, dass jeder Umgang mit personenbezogenen Daten 
entsprechend der nachfolgenden Anforderungen zu protokollieren ist. Dies 
stützt sich auf Kriterium 1. 


Anforderung 7 Die technische Anforderung 7 besteht aus mehreren Daten- 
arten, die gemeinsam den Umfang des Protokolls zur Erhebung personenbezo- 
gener Daten festlegen. Dass ein solches Protokoll grundsätzlich zu erstellen 
ist, ergibt sich für einen Spezialfall aus Kriterium 24. In den anderen Fällen 
ist die Erstellung des Protokolls eine technische Vereinfachung, um gemäß 
der Kriterien 2 und 3 die Beauskunftung der nach Kriterium 13 gespeicherten 
Herkunftsinformationen im Nachhinein zu ermöglichen. Sind die Herkunfts- 
daten nicht anderweitig gespeichert, würde die technische Anforderung 7 die 
rechtlichen Kriterien übererfüllen. Dies widerspricht jedoch keiner der übrigen 
Kriterien, insbesondere nicht Kriterium 40, da eine vollständige Auskunft im 
Interesse des Betroffenen liegt. Für den Inhalt des Protokolls ergibt sich im 
Einzelnen die Angabe der Quelle aus Kriterium 13, die Angabe des Zeitpunktes 
aus Kriterium 31, die Angabe der Kategorie als erweiternder Analogieschluss 
aus Kriterium 16, die Angabe der Organisationseinheit und des IT-Systems 
aus Kriterium 2 in Verbindung mit Kriterium 1, die Angabe des Zwecks aus 
Kriterium 64. 


Anforderung 9 Die technische Anforderung zum Umfang des Protokolls 
zur Übermittlung personenbezogener Daten ergibt sich aus ganz ähnlichen 
Kriterien wie bei der Erhebung. Allerdings gibt es keine Übererfüllung in der 
technischen Umsetzung, da die Protokollierung der Empfänger in Kriterium 15 
immer gefordert ist. Das Kriterium 19 fasst bis auf den Zweck alle inhaltlichen 
Punkte des Protokolls zusammen. Die Kriterien 28 und 29 ergänzen diesen. 
Die übrigen Kriterien geben der Anforderung ihren Kontext. 


Anforderung 10 Das Protokoll zur Veröffentlichung personenbezogener 
Daten setzt sich aus den inhaltlichen Punkten des Kriteriums 20 zusammen. 
Es fordert die Protokollierung von Beginn und Ende der Veröffentlichung. Die 
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Aufnahme von Organisationseinheit und IT-System sind auf das allgemeine 
Prinzip der durchgängigen Historie von Kriterium | zurückzuführen. Kriterium 
42 wirkt explizit einschränkend und verhindert, im Gegensatz zur Anforderung 
9, die Aufnahme der Gegenstelle ins Protokoll. Die Kriterien 28 und 29 
ergänzen die Angabe des Zwecks. 


Anforderung 11 Analog der obigen Anforderungen ergibt sich die Proto- 
kollierung von Sender und Empfänger bei der internen Weitergabe aus den 
Kriterien 1, 14 und 17. Der Zeitpunkt der Weitergabe wurde mit aufgenom- 
men, ist jedoch gemäß Kriterium 32 nur im Einzelfall auskunftspflichtig. Die 
Protokollierung des Zwecks ergibt sich aus den Kriterien 28 und 29. 


Anforderung 12 Die grundsätzliche Existenz der Anforderung und die Proto- 
kollierung von Organisationseinheit und IT-System ergeben sich analog zu den 
übrigen Protokollanforderungen aus Kriterium 1. Als Erweiterung wurde aus 
Kriterium 12 die Speicherung von Name und Typ der Anwendung für gewisse 
Spezialfälle übernommen. Die Speicherung der Zwecke der Verarbeitung ist in 
den Kriterien 28 und 29 festgeschrieben. Dagegen wird die Speicherung des 
Zeitpunkts einer Verarbeitung durch Kriterium 32 optional gestellt und durch 
Kriterium 44 letztendlich untersagt. 


Anforderung 15 Die Anforderung, ein Protokoll über die gespeicherten 
Daten zu erstellen, ergibt sich aus der Kombination des speziellen Kriteriums 
8 mit dem allgemeinen Kriterium 1, welches wiederum die Grundlage für die 
Speicherung von Organisationseinheit und IT-System ist. Die Speicherung 
des genauen Dateipfads und der Metadaten gründet in dem erweiternden 
Kriterium 11. Die Protokollierung des Zwecks ist in den Kriterien 27, 28 und 
29 festgeschrieben. 


Anforderung 19 Die getrennte Speicherung und Verarbeitung der Protokoll- 
daten finden sich, je nach Protokolltyp, in unterschiedlichen Kriterien. Für den 
Zweck gibt Kriterium 30 die unabhängige Speicherung vor. Für die allgemeine 
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Datenhaltung und Datenverarbeitung der Protokolldaten stützen die Kriterien 
68 und 69 die Anforderung. 


Anforderung 23 Die Grundanforderung, Protokolldaten zu speichern, solan- 
ge es keine Löschregel gibt, findet ihren ersten Bezugspunkt in der Speicherdauer 
der Basisdaten gemäß Kriterium 6. Die Löschregel als Löschberechtigung ist 
dem Kriterium 57 entnommen. 


Anforderung 25 Die Löschregel für die Erhebungsprotokolle ist in An- 
forderung 25 verankert. Aufgrund von Kriterium 26 ist die Speicherdauer 
der Erhebungsprotokolle an die Speicherdauer der Übermittlungsprotokolle 
gebunden. Indirekt ist die Speicherdauer damit auch an die in Kriterium 6 
beschriebene Speicherdauer der Basisdaten gebunden. Kriterium 25 wird durch 
die Bindung an die Übermittlungsprotokolle miterfüllt, soweit deren Löschregel 
korrekt ist. 


Anforderung 26 Die Löschregel in Anforderung 26 stützt sich in ihren 
einzelnen Spiegelpunkten mehr oder weniger wortwortlich auf die Kriterien 
22, 23, 25 und 6. Die Kriterien stellen zum Teil nur Forderungen für bestimmte 
Spezialfälle auf. Die Anforderung 26 übererfüllt durch ihre Verallgemeinerung 
die Kriterien, verletzt dabei jedoch keine anderen Kriterien oder grundlegenden 
Prinzipien. 


Anforderung 28 Anforderung 28 ergibt sich wortwörtlich aus Kriterium 46. 
Das Kriterium 6 wird implizit miterfüllt, da nach Abschluss der Verarbeitung 
(Terminierung des Prozesses), der Prozess und damit auch die Basisdaten nicht 
mehr existieren. 


Anforderung 29 Das Kriterium 47 konkretisiert Kriterium 6 für die Spei- 
cherung. Beide münden gemeinsam in der, in Anforderung 29 festgelegten, 
Bindung des Speicherprotokolls an die Basisdaten. 
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Anforderung 39 Das Verbot von Schreibzugriffen auf die Protokolldaten 
von Prozessen außerhalb des Datenschutzauskunftssystems ist eine starke 
technische Spezialisierung der Kriterien 57 und 59, die die Integrität der 
Protokolldaten in allgemeiner Weise fordern. 


Anforderung 40 Anforderung 40 definiert eine auf den Betroffenen be- 
schränkte feingranulare Regel für den lesenden Zugriff, die die Kriterien 65, 66 
und 67 umsetzt. Die Zugriffsregel gilt gemäß Kriterium 66 für die übermittelten 
Auskunftsdaten und gemäß Kriterium 67 für die Protokolldaten selbst. 


Anforderung 55 Die Anforderung an die Vollständigkeit der Protokoll- 
informationen ergibt sich direkt aus Kriterium 2. Dass die Auskunft den 
Protokollinformationen zu entsprechen hat bestimmt sich nach Kriterium 56. 
Die Korrektheit der Auskunft ist Kriterium 60 entnommen. 


Anforderung 58 Die Standardisierung des Interfaces eines Datenschutzaus- 
kunftssystems ist die Voraussetzung für die stellenübergreifende Protokollie- 
rung nach Kriterium 18. Eine zentrale Plattform gemäß Kriterium 62 ist auch 
auf einheitliche Interfaces angewiesen. 


B.3.2 Vollständigkeit der technischen Anforderungen 


Die technischen Anforderungen sind nur in Bezug auf die funktionalen Anfor- 
derungen (Anforderungen 1 bis 29), die sich aus den Kriterien des Auskunfts- 
anspruchs ergeben (Kriterium 1 bis 39), vollständig. Da bereits die Kriterien, 
die über den Auskunftsanspruch hinaus gehen, nicht vollständig sind, können 
es auch die diesbezüglichen technischen Anforderungen nicht sein. 


Die nicht-funktionalen technischen Anforderungen sind nicht erschöpfend, 
da sich beispielsweise aus Kriterium 38 eine lange Liste ergänzender nicht- 
funktionaler Anforderungen ergibt. Das Kriterium eines einfachen und flexiblen 
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Zugangs erfordert die genaue und umfangreiche Formulierung von Usability- 
Anforderungen. 


Die Kriterien 4, 10, 16 und 32 weichen die in anderen Kriterien enthaltenen 
Protokollpflichten für bestimmte Spezialfälle auf. Sie wurden in den tech- 
nischen Anforderungen zum Teil implizit berücksichtigt, erfordern jedoch 
keine vollständige Umsetzung in den Anforderungen. Kriterium 4 ist aber 
insofern wichtig, als dass es eine fortlaufende rekursive Protokollierung des 
Datenschutzauskunftssystems selbst und die damit einhergehenden technischen 
und praktischen Probleme vermeidet. 


Die für die Vollständigkeitsprüfung relevante verkürzte Liste findet sich in 
Tabelle B.3. 


Die vollständige Umsetzung der Kriterien, die nur in einer Anforderung 
resultieren, ist direkt nachvollziehbar und bedarf wie bei der Korrektheit 
keiner weiteren Erläuterung. Die komplexen Kriterien werden in den folgenden 
Absätzen behandelt. 


Kriterium 1 Die Anforderungen 1, 2, 6, 7,9, 10, 11, 12 und 15 umfassen 
alle Teilschritte im Lebenszyklus eines Datums. Sie beinhalten jeweils den 
Speicherort. Über Anforderung 16 ist sichergestellt, dass die Historie keine 
Lücken aufweist. Werden alle Anforderungen erfüllt, ergibt sich eine durch- 
gängige Historie. Die Anforderungen sind demgemäß vollständig im Bezug 
auf Kriterium 1. 


Kriterium 3 Gemäß Kriterium 3 müssen die Anforderungen sicherstellen, 
dass der Personenbezug personenbezogener Daten im Zuge der Auskunft 
herstellbar ist. Um dies zu erreichen, wird in Anforderung 7 die Quelle der 
personenbezogenen Daten genau referenziert. Das entstehende Protokoll wird 
gemäß Anforderung 8 mit einem eindeutigen Identifikator des Betroffenen 
verknüpft. Dadurch kann das Kriterium insgesamt erfüllt werden. 
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Tabelle B.3: Ableitung rein funktionaler technischer Anforderungen aus den rechtlichen Kriterien 
des Auskunftsanspruchs 


Rechtliche Kriterien Technische Anforderungen 


1 1, 2, 6, 7,9, 10, 11, 12, 15, 16 
3 7,8 

6 23, 25, 26, 27, 28, 29 
7 24 

8 15 

9 17 

11 15 

12 12 

13 7 

14 11 

15 9 

19 9 

17 11 

20 10 

21 9 

22 26 

23 26 

24 7 

25 25, 26 

26 25 

27 15 

28 9, 10, 11, 12, 15 
29 9, 10, 11, 12, 15 
30 19 

31 7,9 

33 13 

34 14 


Kriterium 6 Das Kriterium 6 ist die Grundvorgabe für die Speicherfrist der 
Protokolldaten. Die Bindung an die Basisdaten wird fiir die Prozessverarbeitung 
und die Speicherung von den Anforderungen 28 und 29 umgesetzt. Alle übrigen 
Léschregeln (Anforderungen 23, 25, 26 und 27) sind an die beiden erstgenannten 
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Löschregeln zeitlich gebunden und entsprechen so auch Kriterium 6. Da die 
Löschregeln alle Protokollarten behandeln, ist Kriterium 6 insgesamt vollständig 
umgesetzt. 


Kriterium 25 Dieses Kriterium ist eine Spezialregelung für die Löschung 
der Protokolldaten bei der Übermittlung zu Werbezwecken. Sie wird für die 
Übermittlungsprotokolle (Empfänger) in Anforderung 26 direkt übernommen. 
Die Herkunftsinformationen finden sich in den Erhebungsprotokollen nach 
Anforderung 25. Sie sind in ihrer Speicherdauer an Anforderung 26 gebunden. 
Dadurch wird Kriterium 25 insgesamt vollständig umgesetzt. 


Kriterien 28 und 29 Nach diesen Kriterien müssen alle Zwecke der Verwen- 
dung personenbezogener Daten protokolliert werden. Für die Übermittlung 
und die Veröffentlichung findet sich dies in den Anforderungen 9 und 10. Für 
die Speicherung und Verarbeitung ist dies in den Anforderungen 12 und 15 
festgelegt. Die Aufnahme des Zwecks in Weitergabeprotokolle findet sich in 
Anforderung 27. Um alle Zwecke beauskunften zur können, muss ihre Abfolge 
erhalten bleiben. Dies ist in Anforderung 27 enthalten. Somit sind die beiden 
Kriterien vollständig umgesetzt. 


Kriterium 31 Der Zeitpunkt der Erhebung und Übermittlung muss nach 
diesem Kriterium in der Auskunft mitenthalten sein. Für die ordnungsgemäße 
Protokollierung stehen die Anforderungen 7 und 9. Die Übereinstimmung von 
Protokoll und Auskunft wird für dieses Kriterium wie auch für alle vorherge- 
henden Kriterien von Anforderung 55 sichergestellt. Daher ist Kriterium 31 
vollständig von den Anforderungen abgedeckt. 
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C Exkurs: Das koreanische 
Datenschutzrecht 


Datenschutzrecht ist schon lange ein internationales Thema. Personenbezogene 
Daten fließen global. Dieses Kapitel erläutert deshalb am Beispiel Südko- 
reas die Unterschiede zwischen europäischem Datenschutzrecht und dem 
Datenschutzrecht eines Drittlandes. 


Abschnitt C.1 führt in das koreanische Datenschutzrecht, seine historische 
Entwicklung und seine Besonderheiten ein.! Darauf aufbauend vertieft Ab- 
schnitt C.2 die im koreanischen Datenschutzrecht existierenden Transparenz- 
rechte. Das Recht auf Einsichtnahme (Abschnitt C.2.4 kommt dem europäi- 
schen Auskunftsanspruch am nächsten, entspricht ihm jedoch nicht vollständig. 
Dementsprechend ergeben sich für Korea Anforderungen an ein Datenschutz- 
auskunftssystem, die von denen aus Kapitel 4 abweichen. Diese Anforderungen 
sind in Abschnitt C.3 beschrieben. 


C.1 Übersicht über das koreanischen 
Datenschutzrecht 


Südkorea ist eines der aufstrebenden Länder Ostasiens. Die wirtschaftliche 
Entwicklung der letzten beiden Jahrzehnte, insbesondere die Etablierung 


! Der Abschnitt C.1 wurde bereits in Bier, DuD 2013, 457 veröffentlicht. 

? OECD, Key Tables from OECD - Gross domestic product in US dollars, April 2013, http://www. 
oecd-ilibrary.org/economics/gross-domestic-product-in-us-dollars_2074384x-table3, abgerufen 
am 9. Mai 2017. 
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eines innovativen IT-Sektors,! machen das „Land der Morgenfrische“ zu einem 
interessanten Handelspartner und Akteur auf der globalen Bühne.” Südkorea 
ist inzwischen Mitglied der Organisation for Economic Cooperation and 
Development (OECD),? Teilnehmer an den G20-Gipfeln und stellte bis Anfang 
2017 auch den Generalsekretär der Vereinten Nationen. Die Beziehungen zur 
Europäischen Union streben stetig ein intensivierendes Niveau an. Das 2010 
geschlossene Freihandelsabkommen ermöglicht einen fruchtbaren Austausch 
zwischen Südkorea und dem europäischen Wirtschaftsraum.* 


Durch die immer stärkere Dominanz des IT-Sektors erstreckt sich dieser 
Austausch auch auf den Transfer von Daten, eingeschlossen solcher mit Per- 
sonenbezug. Ein treibender Faktor für die Entwicklung des koreanischen 
Datenschutzrechts ist daher die Anpassung des eigenen Datenschutzes an die 
Anforderungen der internationalen Wirtschaftspartner, insbesondere die Aner- 
kennung des Datenschutzes als Rechtsraum mit angemessenem Schutzniveau 
nach Art. 25 95/46/EG. Die rechtlichen Entwicklungen in der Europäischen 
Union finden daher auch in Korea fortlaufend Beachtung. ° 


Andererseits sollte auch das koreanische Datenschutzrecht in Europa Beach- 
tung finden. Praktischer Datenschutz wird durch die Grundeinstellungen und 
Vorgaben in der verwendeten Hard- und Software mitbestimmt (Privacy by 
Design (PbD) und Privacy by Default).° Mobile Geräte werden als Mittel zum 
Zugriff auf und zur Erhebung von personenbezogenen Daten immer wichtiger. 
Nun liegt ein maßgeblicher Anteil des weltweiten Smartphone-Marktes in 


! Größen wie Samsung, Hyundai und LG, aber auch Suchmaschinen- und Social-Media-Betreiber 
wie Daum Communications und Naver. 

2 Weltbank, Doing Business — Measuring Business Regulations, 2013, http://www.doingbusiness. 
org/data/exploreeconomies/korea, abgerufen am 9. Mai 2017. 

3 OECD, Members and Partners, http://www.oecd.org/about/membersandpartners, abgerufen am 
9. Mai 2017. 

4 Beschluss des Rates vom 16.09.2010, 201 1/265/EU. 

5 Beispielsweise das Recht auf Vergessen, siehe http://koreatimes.co.kr/www/news/nation/2013/ 
03/113_132348.html, abgerufen am 9. Mai 2017. 

© Cavoukian 2011. 
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südkoreanischer Hand. ! Dortige Datenschutzbestimmungen beeinflussen das 
Vorgehen und die Kultur der dort produzierenden Unternehmen. 


Durch die dynamische Struktur und Innovationskraft der koreanischen Gesell- 
schaft können bestimmte Elemente der koreanischen Datenschutzgesetzgebung 
auch als Vorbild für europäische Regelungen dienen. Das neu geschaffene 
Gesetz zum Schutz personenbezogener Daten” kann eine wertvolle Funktion 
in der Rückspiegelung auf die neuere europäische Gesetzgebung bieten. 


C.1.1 Geschichtlicher Hintergrund und 
verfassungsrechtliche Verankerung 


Das traditionelle koreanische Recht war stark im Konfuzianismus verankert.” 
Aufgrund der japanischen Okkupation in den Jahren 1905 bis 1945 wurde 
jedoch das in Japan rezipierte kontinentaleuropäische Recht in Korea durchge- 
setzt.* In der sich anschließenden Zeit der US-amerikanischen Verwaltung und 
den Gründungsjahren der Republik Korea gewann insbesondere das deutsche 
Recht weiter an Einfluss.” Der deutsch-amerikanische Staatsrechtler Ernst 
Fraenkel war bei der Überarbeitung des koreanischen Rechts beratend tätig.® 
Erst durch die engen wirtschaftlichen Beziehungen zu den USA wirkte das 
anglo-amerikanische verstärkt auf das koreanische Rechtssystem ein, so dass 
sich heute eine Mischung unterschiedlicher Strömungen im koreanischen Recht 
wiederfindet.’ Im Datenschutzrecht überwiegt jedoch die kontinentaleuropäi- 
sche Tradition und Gesetzgebung. 


! Der weltweite Marktanteil des koreanischen Marktführers Samsung lag 2012 allein bei 30,3%, 
IDC, Worldwide Quarterly Mobile Phone Tracker, https://www.idc.com/getdoc.jsp?containerld= 
prUS23916413, abgerufen am 9. Mai 2017. 

2 Personal Information Protection Act (7 9] 442. X =) vom 29. März 2011; koreanische 
Fassung abrufbar unter http://www.law.go.kr; englische Ubersetzung abrufbar unter http: 
//elaw.klri.re.kr. 

3 Seong-Cheon Kim in: Korea Legislation Research Institute 2010, 4. 

4 Sang-Yong Kim in: Korea Legislation Research Institute 2010, 5 f. 

5 Byung-Jun Lee in: Korea Legislation Research Institute 2010, 79; Seong-Cheon Kim in: Korea 
Legislation Research Institute 2010, 243. 

6 Ky-Byung Park in: Korea Legislation Research Institute 2010, 51. 

7 Sang-Yong Kim in: Korea Legislation Research Institute 2010, 9. 
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Verankert ist das koreanische Datenschutzrecht im Artikel 17 der Verfassung 
der Republik Korea (4 75 H). ! Dieser setzt den Schutz der Privatsphäre 
(A 3%) der Bürger als Ziel. Zugrunde liegt diesem Ziel die Garantie der 
unverletzlichen, fundamentalen Menschenrechte (2 7} 4] 2] 7) #4 17) 
in Artikel 10. Das Recht auf informationelle Selbstbestimmung wird vom 
koreanischen Verfassungsgerichtshof seit einem Urteil im Jahr 2005? zu- 
mindest teilweise anerkannt, bedarf jedoch noch der Konkretisierung in der 
Rechtswirklichkeit.* 


C.1.2 Einfachgesetzliche Struktur 


Bis zur Neuregelung im Jahr 2011 ähnelte das koreanische Datenschutzrecht 
einem Flickenteppich mit Bereichen großer Regelungsdichte, andererseits aber 
auch mit ebenso großen Lücken in mehreren Bereichen.* Für den Bereich 
öffentlicher Stellen war bis 2011 das Gesetz zum Schutz personenbezogener 
Daten bei öffentlichen Stellen (227) 2] AIR Boo] HIN) 
maßgeblich. Sein Schwerpunkt lag hauptsächlich auf Transparenzregularien. 
Im nicht-öffentlichen Bereich (Privatwirtschaft) existierten eine ganze Reihe 
spezialgesetzlicher Regelungen, die sich zum Teil nur an einzelne Branchen 
oder Technologien richteten.> 


Durch das neue Gesetz zum Schutz personenbezogener Daten (Personal In- 
formation Protection Act (PIPA), 12H 435%) vom 29. März 2011 
wurde erstmalig ein einheitliches nationales Datenschutzgesetz geschaffen. 


! Koreanische Fassung abrufbar unter http://www.law.go.kr; englische Übersetzung abrufbar unter 
http://elaw.klri.re.kr. 

2 Entscheidung des koreanischen Verfassungsgerichts vom 26.5.2005 (@1 A] 2005.05.26 99% 
245135, HAX, 17/1, 668%). 

3 Lee 2007, 52. 

* Lee 2007, 52 f. 

5 Beispielsweise der „Act on Consumer Protection in Electronic Commerce” (2%47]50]] 
AV 2] 2B] A} SO 2S YS), der “Use and Protection of Credit Information Act” (Al 4 H 
2} oO] 2B) H SoHE) oder der “Use and Protection of Location Information Act” (A 2] 
AS yo] -B-5 ol toby S). 
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Das entsprechende Gesetz für den öffentlichen Bereich wurde dadurch kom- 
plett ersetzt. Im Privatsektor gelten jedoch die spezialgesetzlichen Regelungen 
größtenteils noch weiter und ergänzen das allgemeine Datenschutzgesetz 
durch weitergehende Regelungen. Insbesondere das Gesetz zur Förderung der 
Informations- und Kommunikationstechnologie und des Datenschutzes (74 8 
SAY Oo] 22218 JHH AAYE) wird sogar noch erweitert. 
Aufgrund der Neuheit des allgemeinen nationalen Datenschutzgesetzes bediir- 
fen auch viele weitere spezialgesetzliche Regelungen noch der Anpassung, um 
mit den allgemeinen Regelungen konsistent zu sein. 


C.1.3 Systematik des Gesetzes zum Schutz 
personenbezogener Daten 


Das koreanische Gesetz zum Schutz personenbezogener Daten gliedert sich in 
neun Kapitel. Im ersten Kapitel, dem allgemeinen Teil, werden Definitionen 
und grundlegende Prinzipien behandelt. Kapitel 2 befasst sich mit der nationa- 
len Datenschutzkommission, welche unter anderem mit der Erstellung eines 
Dreijahresplans für Datenschutzmaßnahmen der Regierung befasst ist. Der 
Kern der datenschutzrechtlichen Regelungen findet sich im dritten Kapitel. 
Dort werden die Bedingungen und Einschränkungen zur Erhebung, Nutzung 
und Übermittlung personenbezogener Daten festgelegt. Kapitel 4 befasst sich 
mit technischen und organisatorischen Maßnahmen des Datenschutzes, wie 
der Etablierung eines Datenschutzbeauftragten. Im fünften Kapitel werden die 
Betroffenenrechte behandelt. Die Kapitel 6 bis 9 enthalten Regularien zum 
Schlichtungsausschuss, zu Sammelklagen und Strafvorschriften. Insgesamt 
folgt das Gesetz einer klaren Linie und differenziert nur an wenigen Stellen 
zwischen öffentlichen und nicht-öffentlichen Stellen. 


C.1.4 Das personenbezogene Datum 
Als personenbezogenes Datum (71 9) X 2) wird jede Information bezeichnet, 


die sich auf eine lebende Person bezieht und mit Hilfe derer die in Frage 
stehende Person identifiziert werden kann. Dies schließt nach Art. 2 Nr. 1 PIPA 


377 


C Exkurs: Das koreanische Datenschutzrecht 


auch Informationen ein, die erst in Kombination mit anderen Informationen 
eine identifizierende Wirkung besitzen (sogenannte Quasi-Identifier). Explizit 
als zu den personenbezogenen Daten gehörend werden der Name der Person, 
die Resident Registration Number (RRN) sowie Abbildungen genannt. Damit 
entspricht der Begriff des personenbezogenen Datums nicht exakt dem des 
europäischen Rechtsraumes. Es sind nämlich nicht jene Daten personenbe- 
zogene Daten, die einer natürlichen Personen zuordenbar sind, sondern jene 
Daten, die die eindeutige Zuordnung ermöglichen. Die Grenzen sind jedoch 
fließend. Die meisten Daten, die einer Person zuordenbar sind, können auch 
als Quasi-Identifier aufgefasst werden. Ob sich in der Rechtspraxis in der 
Konsequenz tatsächlich ein Unterschied zum europäischen Datenschutzrecht 
ergibt, wird sich erst in der Zukunft zeigen. 


C.1.5 Prinzipien/Grundsätze 


Die Grundprinzipien des koreanischen Datenschutzrechts sind, an zentraler 
Stelle gesammelt, in Art. 3 PIPA kodifiziert. Sie lehnen sich stark an die 
OECD-Richtlinien zum Schutz personenbezogener Daten an.! An erster Stelle 
stehen in Absatz 1 die Zweckbestimmung (5 4), die Rechtmäßigkeit der 
Datenerhebung und die Datensparsamkeit. Damit werden die OECD-Prinzipien 
„Purpose Specification“ und „Collection Limitation“ angesprochen. In Absatz 2 
wird die Zweckbestimmung um die Zweckbindung ergänzt (OECD: „Use Limi- 
tation“). In Bezug auf die Datensparsamkeit wird in Absatz 7 insbesondere auch 
gefordert, dass personenbezogene Daten soweit möglich anonymisiert werden 
(222) E]). Die Beweislast für eine zweckentsprechende datenminimale Erhe- 
bung liegt bei der verantwortlichen Stelle (Art. 16 Abs. 1 PIPA). Art. 3 Abs. 3 
PIPA gibt fast wörtlich das „Data Quality“-Prinzip der OECD-Richtlinien wie- 
der. Die enthaltenen datenbezogenen Prinzipien sind die Korrektheit 23-9), 
Vollstindigkeit( 2+ 4 73) und Aktualität (2) 41/3) der Daten. Auch die Da- 
tensicherheit, unter Einbezug der Risiken für die Persönlichkeitsrechte des 
Betroffen, wird im Folgenden als Grundprinzip angeführt (OECD: „Security 


' Organization for Economic Co-operation and Development 2002. 
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Safeguards“). Transparenzprinzipien (OECD: „Openness“ und „Individual 
Participation“), wie die Forderung nach einer Datenschutzrichtlinie und das 
Recht des Betroffenen auf Einsicht in die eigenen personenbezogenen Da- 
ten, finden in Absatz 5 Erwähnung. Die Minimierung des Eingriffs in die 
Privatsphäre des Betroffenen und die Herstellung einer Vertrauensbeziehung 
zwischen verantwortlicher Stelle und Betroffenem werden als eigenständige 
Ziele in Absatz 6 und 8 formuliert. Während die OECD-Richtlinie die Verant- 
wortlichkeit der verantwortlichen Stelle einfordert („Accountability“), wird 
mit der Vertrauensbeziehung ein stärker sozialer Aspekt der Datenverarbeitung 
angesprochen. Verantwortlichkeit ist dann ein möglicher Anker für Vertrauen. 
Im Ergebnis wird durch die umfassende Zielbestimmung in Artikel 3 schon 
zu Beginn des Gesetzes ein gewisser Rahmen für die Auslegungspraxis ge- 
schaffen. Gleichzeitig schafft das Gesetz eine positive, datenschutzbejahende 
Außenwirkung, die auch für den Laien verständlich ist, der sich in den Tiefen 
des Gesetzes sonst verlieren würde. Jedes der Prinzipien wird in den folgenden 
Artikeln mit detaillierten Regelungen gefüllt und steht so nicht nur als leere 
Hülle im Raum. 


C.1.6 Institutionen und Rollen 


Neben dem Betroffenen (4 1 # 7]]), definiert in Art. 2 Nr. 3 PIPA, und der 
verantwortlichen Stelle ¢] 4 H Aj 8] 3Ţ, definiert in Art. 2 Nr. 5 PIPA, 
findet sich auch der betriebliche oder behördliche Datenschutzbeauftragte 
ANA BS N Z}) im Gesetz. Nach Art. 31 Abs. 1 PIPA ist dieser von 
jeder verantwortlichen Stelle zu ernennen. Wie in den meisten Fällen wird auch 
hier nicht zwischen öffentlichen und nicht-öffentlichen Stellen unterschieden. 
Der Datenschutzbeauftragte ist für die Aufstellung eines Datenschutzplanes, die 
Verbesserung des Datenschutzniveaus durch interne Kontrollmechanismen und 
Bildungsmaßnahmen sowie die Behandlung von Beschwerden verantwortlich. 
Ähnlich dem deutschen Recht genießt der Datenschutzbeauftragte auch in 
Korea einen besonderen Schutz, der in Absatz 5 jedoch nur sehr allgemein 
formuliert wird. Die verantwortliche Stelle wird aufgefordert, Sorge dafür zu 
tragen, dass der Datenschutzbeauftragte durch seine Tätigkeit oder aufgrund 
seiner Tätigkeit keine Nachteile ohne besondere Rechtfertigung erleidet. 
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Institutionell ist zunächst die nationale Datenschutzkommission (JAH 
HZY 293]) zu nennen. Die Kommission agiert unabhängig, ist jedoch dem 
Präsidenten untergeordnet (Art. 7 Abs. 1 PIPA). Den bis zu 15 Mitgliedern 
gehören ein Vorsitzender und ein ständiges Mitglied an (Art. 7 Abs. 2 PIPA). Die 
Mitglieder der Kommission sollen sich aus einer breiten Auswahl von Experten 
des Datenschutzes zusammensetzen, die nach im Gesetz festgelegten Regularien 
ausgewählt werden. Die Kommission hat ein weites Spektrum unterschiedlicher 
Aufgaben. Sie verfasst unter anderem Stellungnahmen zur Interpretation des 
Datenschutzrechts (Art. 8 Abs. 1 Nr. 4 PIPA) und erstellt jährlich einen 
Datenschutzbericht (Art. 8 Abs. 1 Nr. 10 i. V.m. Art. 67 Abs. 1 PIPA). Auch 
die Weiterentwicklung des Datenschutzrechts als Forschungsaufgabe ist der 
Kommission übertragen (Art. 8 Abs. 1 Nr. 2 PIPA). Insgesamt ist sie die 
Institution, die in ihrer Rolle dem Bundesbeauftragten für den Datenschutz 
am nächsten kommt. In Folge dessen ist sie auch Mitglied der „International 
Conference of Data Protection and Privacy Commissioners“. ! Unter Beteiligung 
der Datenschutzkommission erstellt der Minister für öffentliche Verwaltung und 
Sicherheit (99 0+ 4 4. 4} +4) federführend den Dreijahresplan der Regierung 
fiir den Datenschutz (Art. 9 Abs. 1 PIPA). 


Die Streitschlichtungskommission (44 44 % 4 9] 2]3]) ist eine Besonderheit 
des koreanischen Datenschutzrechtes. Sie setzt sich aus bis zu 20 Mitgliedern, 
inklusive eines Vorsitzenden und eines ständigen Mitglieds, zusammen (Art. 40 
Abs. 2 PIPA). Das Schlichtungsverfahren dient der einvernehmlichen Klärung 
von Datenschutzverstößen. Es ist einer Sammelklage zwingend vorgeschaltet 
(Art. 55 Abs. 1 PIPA). Antragsberechtigt ist jede in einen Datenschutzkonflikt 
verwickelte Partei (Art. 43 Abs. 1 PIPA). 


Ein weiterer Akteur ist die KCC (Korean Communication Commission, 
Y3542]2393]), der nach Art. 4 Abs. 2 Nr. 6 des Gesetzes zur Förderung 
der Informations- und Kommunikationstechnologie und des Datenschutzes der 
Datenschutz in Kommunikationsnetzen obliegt. 


l http://www.pipe.go.kr/cmt/english/functions/intactivity.do, abgerufen am 9. Mai 2017. 
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Eine bedeutende Rolle in der Entwicklung des koreanischen Datenschutzes 
spielt auch die KISA (Korea Internet Security Agency, t=; ©] 49 yl AEA). 
Ihre Einrichtung wird in Art. 52 des Gesetzes zur Förderung der Informations- 
und Kommunikationstechnologie und des Datenschutzes festgeschrieben. Ne- 
ben technischen Aspekten des Internets wie IPv6 und Domainregistrierung 
obliegt ihr die Aufgabe den Datenschutz zu fordern. Daher ist als Teil der KISA 
das ,,Personal Information Protection Center“ etabliert (Art. 52 Abs. 3 Nr. 9). 
Hervorzuheben ist ebenfalls, dass sie das Sekretariat der Streitschlichtungs- 
kommission beheimatet.! Die KISA arbeitet im Bereich der IT-Sicherheit eng 
mit der KCC zusammen, so etwa beim Vorgehen in Folge von widerrechtlichem 
Zugriff auf personenbezogene Daten nach Art. 49-2. 


C.1.7 Privacy Impact Assessment 


Neben den technischen und organisatorischen Maßnahmen zum Schutz per- 
sonenbezogener Daten, die der verantwortlichen Stelle auferlegt werden (Art. 
29 PIPA), steht die Analyse der möglichen Risiken für den Betroffenen, das 
Privacy Impact Assessment (A NRH A A 7J. Dieses ist verpflichtend 
für alle öffentlichen Stellen, sofern eine Maßnahme durchgeführt werden soll, 
die wahrscheinlicherweise die Persönlichkeitsrechte des Betroffenen verletzt 
(Art. 33 Abs. 1 PIPA). Die verantwortliche öffentliche Stelle hat dann alle 
Risikofaktoren und Verbesserungsvorschläge an den Minister für öffentliche 
Verwaltung und Sicherheit weiterzugeben. Das eigentliche Assessment wird 
dann von einer vom Minister festgelegten Stelle durchgeführt. Einflussfaktoren 
auf das Assessment sind im Regelfall die Menge der verarbeiteten personenbe- 
zogenen Daten, die Übermittlung an Dritte, und das Risiko des Eingriffs in 
die Persönlichkeitsrechte (Art. 33 Abs. 2 PIPA). Auch einer nicht-öffentlichen 
verantwortlichen Stelle wird vom Gesetzgeber nahe gelegt, Privacy Impact 
Assessments durchzuführen (Art. 33 Abs. 8 PIPA). Wie ein Privacy Impact 
Assessment auszusehen hat, wird unter anderem durch die Stellungnahmen der 
nationalen Datenschutzkommission beeinflusst (Art. 8 Abs. 1 Nr. 6 PIPA). 


1 http://www.kisa.or.kr/eng/aboutkisa/organization.jsp, abgerufen am 9. Mai 2017. 
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C.1.8 Videoüberwachung 


Der Einsatz von Videoüberwachungsanlagen (° 4} 4 4.7] 2] 7] 7]) ist im 
koreanischen Datenschutzrecht besonders streng reglementiert.! Als Video- 
überwachungsanlage gilt jedes durch Dekret definierte System, das Bilddaten 
oder ähnliches aufnimmt und permanent an einem bestimmten Ort installiert 
wurde. Dabei ist es unerheblich, ob die Daten aufgezeichnet oder nur per 
Netzwerk übertragen werden (Art. 2 Nr. 5 PIPA). Kameraattrappen fallen damit 
nicht unter den Anwendungsbereich des Gesetzes. Auf der anderen Seite ist die 
Definition nicht auf Aufnahmen im Bereich des sichtbaren Lichts beschränkt. 


Das Dekret zum PIPA listet im Einzelnen in Art. 3 folgende Anlagen als 
Videoüberwachungsanlagen auf: 


e CCTV-Anlagen, die fest installiert sind und eine kontinuierliche Auf- 
zeichnung oder Beobachtung ermöglichen, gemeinsam mit ihren Auf- 
zeichnungseinrichtungen 


e Netzwerk-Kameras zur flexiblen Fernüberwachung 


Die Installation und Inbetriebnahme von Videoüberwachungsanlagen unterliegt 
zunächst einem grundsätzlichen Verbot (Art. 25 Abs. 1 PIPA). Ausnahmen 
gibt es nur für im Gesetz klar definierte Zwecke, nämlich der Verhinderung 
und Aufklärung von Verbrechen (Nr. 2), der Sicherheit (Safety), insbesondere 
dem Brandschutz, (Nr. 3) und der Verkehrsüberwachung (Nr 4 und 5). Weitere 
zulässige Zwecke können durch Gesetz definiert werden (Nr. 1). Bis auf wenige 
Ausnahmen (z.B. Gefängnisse und Krankenhäuser) besteht auch für diese 
Zwecke ein Verbot in Räumlichkeiten mit besonderer Sensibilität in Bezug auf 
die Privatsphäre. Beispielhaft genannt werden Toiletten, Bäder, Saunas und 
Umkleideräume (Art. 25 Abs. 2 PIPA). 


Voraussetzung für den Betrieb von Videoüberwachungsanlagen durch öf- 
fentliche Stellen ist eine vorhergehende Anhörung der Betroffenen und die 
Konsultation von Datenschutzexperten (Art. 25 Abs. 3 PIPA). In Verbindung 


! Auch die grundsätzliche Wirksamkeit ist immer wieder in der Diskussion, so z.B. http: 
//koreatimes.co.kr/www/news/nation/2011/09/113_95660.html, abgerufen am 9. Mai 2017. 
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mit den Vorschriften des Art. 33 PIPA ist die Durchführung eines Privacy 
Impact Assessments für Videoüberwachungsanlagen in den meisten Fällen 
geboten. 


Die Transparenz der Videoüberwachung ist entscheidender Bestandteil für 
deren rechtmäßigen Betrieb. Installierte Systeme sind entsprechend zu kenn- 
zeichnen (Art. 25 Abs. 4 PIPA), Richtlinien zum Betrieb der Anlage sind zu 
formulieren (Art. 25 Abs. 7 PIPA). Ergänzend zu den allgemeinen Datenschutz- 
regularien wird die Bindung des Betriebs von Videoüberwachungsanlagen 
an den zum Zeitpunkt der Installation festgelegten Zweck besonders hervor- 
gehoben (Art. 25 Abs. 5). Insbesondere die nachträgliche Einführung einer 
Aufzeichnungsfunktion ist unzulässig. 


C.1.9 Betroffenenrechte 


Im Gegensatz zu Japan sind die Individualrechte des Betroffenen in Korea 
integraler Bestandteil des Datenschutzrechts. ! 


Wichtiges Recht des Betroffenen ist die Möglichkeit, Einblick in seine perso- 
nenbezogenen Daten zu erhalten (Art. 35 Abs. 1 PIPA). Wurden die personen- 
bezogenen Daten von Dritten erhoben, ist der Betroffene außerdem über die 
Quelle und den Zweck der Erhebung zu informieren (Art. 20 Abs. 1 PIPA). Eine 
zusätzliche Informationspflicht besteht, wenn auf personenbezogene Daten 
unberechtigt zugegriffen wird. In diesem Fall ist der Betroffene unverzüglich 
über die verlorengegangenen Daten und die Umstände des Datenverlustes zu 
informieren (Art. 34 Abs. 1 PIPA). 


Auf dieser Informationsgrundlage kann der Betroffene fordern, dass seine 
personenbezogenen Daten korrigiert (% 4) oder gelöscht (+7]]) werden (Art. 
36 Abs. 1 PIPA) oder dass die Verarbeitung der Daten eingestellt (9 %]) wird 
(Art. 37 Abs. 1 PIPA). 


1 Wakabayashi, DuD 2012, 327 (327). 
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C.1.10 Wirksamkeit 


Die Durchsetzungsfähigkeit des Datenschutzrechts wird durch mehrere Maß- 
nahmen sichergestellt. Erstens wurden Sammelklagen (F7] 2) in Form 
von Verbandsklagen ermöglicht. Sollte durch eine verantwortliche Stelle nach 
einem Datenschutzverstoß ein Schlichtungsspruch gemäß Art. 49 PIPA zu- 
rückgewiesen werden, sind Verbraucherschutzorganisationen berechtigt, Klage 
einzureichen (Art. 51 PIPA).! Zweitens sind schwere Datenschutzverstöße 
strafbewehrt. Je nach Verstoß droht eine Gefängnisstrafe von bis zu 10 Jahren 
oder eine Geldbuße von bis zu 100 Mio. KRW? (Art. 70 ff. PIPA). Zivilrechtlich 
hat der Betroffene Schadensersatzansprüche gegen die verantwortliche Stelle, 
wenn der Schaden auf eine Verletzung des Datenschutzgesetzes durch die 
verantwortliche Stelle zurückzuführen ist (Art. 39 Abs. 1 PIPA). Dabei wird 
unterstellt, dass der Gesetzesverstoß vorsätzlich erfolgte. Die Beweislast, um 
sich von diesem Vorwurf zu exkulpieren, liegt bei der verantwortlichen Stelle. 


C.2 Transparenzrechte im koreanischen 
Datenschutzrecht 


Gemäß Art. 3 Abs. 5 PIPA ist die verantwortliche Stelle dazu verpflichtet, eine 
Datenschutzrichtlinie (i. V.m. Art. 4 Nr. 3) PIPA und Informationen über die 
Rechte des Betroffenen zu veröffentlichen. Dies stellt den Einstiegspunkt zur 
Wahrnehmung der Transparenzrechte dar. Besonders hervorgehoben wird das 
Recht auf Einsichtnahme in die personenbezogenen Daten (right to inspection, 
NAARS) SZ), das in Art. 4 Nr. 3 PIPA verankert ist und in Art. 35 im 
Detail beschrieben wird. 


1 So erfolgt gegen Apple, siehe http://koreatimes.co.kr/www/news/nation/2013/01/113_ 129093. 
html, abgerufen am 9. Mai 2017. 
2 Entspricht etwa 80 000 €. 
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Die Hinweis- und Kennzeichnungspflichten, Aufklärungspflichten, Unter- 
richtungspflichten sowie Benachrichtigungspflichten sind auf die einzelnen 
Eingriffsermächtigungen verteilt. 


C.2.1 Aufklärungs-, Unterrichtungs- und 
Benachrichtigungspflichten 


Erhebt eine verantwortliche Stelle personenbezogene Daten mit der Einwil- 
ligung des Betroffenen, ist dieser gemäß Art. 5 Abs. 2 S. 2 PIPA zuvor über 
folgende Sachverhalte aufzuklären: 


1. Die Zwecke für die die personenbezogenen Daten erhoben und verwendet 
werden; 


2. Die personenbezogenen Daten, die gesammelt werden sollen; 


3. Der Zeitraum in dem die personenbezogenen Daten gespeichert und 
verwendet werden sollen; 


4. Die Rechte des Betroffenen und die Nachteile, die bei der Verweigerung 
der Einwilligung zu erwarten sind. 


Möchte die verantwortliche Stelle die personenbezogenen Daten unter Ein- 
willigung des Betroffenen übermitteln, hat sie nach Art. 17 Abs. 2 S. 2 PIPA 
die selben Informationen auch im Bezug auf den Empfänger bereitzustel- 
len. Darüber hinaus hat sie den Betroffenen über die jeweiligen Empfänger 
selbst zu informieren. Gleiches gilt nach Art. 8 Abs. 3 S. 2 PIPA auch bei 
Zweckänderungen. 


Werden die personenbezogenen Daten von einem Dritten erhoben, ist der 
Betroffene gemäß Art. 20 Abs. 1 PIPA augenblicklich über die Herkunft 
der personenbezogenen Daten, den Zweck der Datenverarbeitung und die 
Betroffenenrechte zu informieren. 
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C.2.2 Hinweis- und Kennzeichnungspflichten bei 
Videoüberwachungsanlagen 


Da Videoüberwachungsanlagen eine unspezifische Gruppe von Personen be- 
treffen, ersetzen Hinweis- und Kennzeichnungspflichten die Benachrichtigungs- 
pflichten. Die Hinweistafel gemäß Art. 25 Abs. 4 PIPA muss nach Art. 24 des 
zugehörigen Präsidialen Dekrets folgende Informationen umfassen: 


e den Zweck der Aufstellung (44 4]-3 4) 

° Den Standort der Videoüberwachungsanlage (423) 

e die Reichweite der Videoüberwachungsanlage (4+ 93 9] ) 

e den Zeitraum, in dem Aufzeichnungen vorgenommen werden (A] Z} 


e den verantwortlichen Geschäftsführer (2+ 2] 2] Q 3} und Kontaktinfor- 
mationen (I%7]) 


Die Hinweistafel ist so anzubringen, dass sie für den Betroffenen leicht zu 
erkennen ist. Wird die Videoüberwachung in einem Gebäude flächendeckend 
durchgeführt, können die Informationen gesammelt am Eingang ausgehängt 
werden. Besteht keine große Gefahr des Überwachungsdrucks (z. B. bei Ver- 
kehrsüberwachungsanlagen) oder lassen es die räumlichen Gegebenheiten 
nicht zu (z.B. in der freien Natur), können die notwendigen Informationen 
ersatzweise auf der Webseite des Betreibers veröffentlicht werden. Ist auch dies 
nicht möglich, ist eine anderweitige Veröffentlichung (z. B. in Tageszeitungen) 
vorgesehen. Militärische Einrichtungen und Einrichtungen der öffentlichen 
Sicherheit sind von den Hinweispflichten ausgenommen. 


Insgesamt gehen die Kennzeichnungspflichten weit über die, in Deutschland 
meist anzutreffenden, DIN-Logos zur Videoüberwachung hinaus. 
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C.2.3 Datenschutzrichtlinie 


Jede verantwortliche Stelle muss eine Datenschutzrichtlinie (Personal Infor- 
mation Management Policy, 34 ž Z] ¥} 4) etablieren. Diese beschreibt 
nach Art. 30 Abs. 1 S. 2 PIPA i. V.m. Art. 32 Abs. 1 des Präsidialen Dekrets, 


e für welche Zwecke personenbezogene Daten verarbeitet werden, 

e den Zeitraum, für den die jeweiligen Daten gespeichert werden, 

e Übermittlungsvorgänge an Dritte, 

e Auftragsverarbeitungen, 

e die Rechte und Pflichten des Betroffenen, 

e die Datenarten verarbeiteter personenbezogener Daten, 

e Löschregeln und -bestimmungen sowie 

e die Vorkehrungen zum sicheren Betrieb der Verarbeitungsanlagen. 


Die Datenschutzrichtlinie ist auf der Webseite der verantwortlichen Stelle zu 
veröffentlichen (Art. 32 Abs. 2 Präsidiales Dekret). Ist dies nicht möglich, ist 
sie auf anderem Wege zu veröffentlichen oder dem Betroffenen gegenüber 
kenntlich zu machen (Art. 32 Abs. 3 Präsidiales Dekret). 


Für den Betrieb von Videoüberwachungsanlagen ist eine getrennte Richtlinie 
zu erstellen und zu veröffentlichen (Art. 25 Abs. 7 PIPA). Diese beinhaltet nach 
Art. 25 Abs. 1 des Präsidialen Dekrets noch umfangreichere Informationen: 


e die Grundlage und den Zweck der Aufstellung der Videoüberwachungs- 
anlagen 


e die Anzahl, den Ort und die Reichweite der Videoüberwachungsanlagen 


e den Manager, die verantwortliche Abteilung und die Zugriffsberechtigten 
für die Videodaten 


e die Aufzeichnungszeit, -dauer und -orte sowie die verwendeten Verar- 
beitungsmethoden 
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die Uberpriifungsmethoden des Betreibers 


die Wege auf denen vom Recht der Einsichtnahme Gebrauch gemacht 
werden kann 


die technischen, organisatorischen und physischen Maßnahmen zum 
Schutz der Bilddaten 


andere Informationen, die notwendig sind, um die Einrichtung und den 
Betrieb der Videoüberwachungsanlage zu beschreiben 


Insgesamt bieten die Datenschutzrichtlinien dem Betroffenen eine umfangreiche 
Quelle, um erste Informationsbedürfnisse allgemeiner Art zu befriedigen. 
Auf dieser Grundlage kann er fundiert entscheiden, ob und welche weiteren 
Betroffenenrechte er wahrnehmen möchte. 


C.2.4 Recht auf Einsichtnahme 


Das Recht auf Einsichtnahme ergibt sich aus Art. 35 PIPA. Es gibt dem 
Betroffenen das Recht, bei der verantwortlichen Stelle Einsichtnahme in die 
über ihn gespeicherten personenbezogenen Daten zu verlangen. Der Antrag 
ist schriftlich bei der verantwortlichen Stelle einzureichen (Art. 41 Abs. 1 
Präsidiales Dekret) 


Die Einsichtnahme ist innerhalb von 10 Tagen zu gewähren (Art. 35 Abs. 3 
S. 1 PIPA i. V.m. Art. 41 Abs. 3 Präsidiales Dekret). Kann die Frist nicht 
eingehalten werden, ist der Betroffene zu informieren und die Verzögerung zu 
begründen (Art. 35 Abs. 3 S. 2 PIPA i. V. m. Art. 42 Abs. 2 Präsidiales Dekret). 


Das Einsichtsrecht muss nicht höchstpersönlich wahrgenommen werden. Al- 
ternativ kann ein Stellvertreter dazu beauftragt werden, die Einsichtnahme 
vorzunehmen (Art. 38 Abs. 1 PIPA). Die gesetzliche Regelung geht aller- 
dings vom Grundtenor her davon aus, dass die Einsichtnahme vor Ort bei der 
verantwortlichen Stelle stattfindet. Da die verantwortliche Stelle die genauen 
Modalitäten selbst definieren kann, kann sie jedoch auch zur eigenen Arbeits- 
erleichterung und zu Gunsten des Betroffenen auf eine elektronische Einsicht 
zurückgreifen. 
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Die Informationen, die der Einsicht zugänglich sind, umfassen nach Art. 41 
Abs. 1 des Präsidialen Dekrets 


e den Gegenstand und Inhalt der personenbezogenen Daten, 
e den Zweck der Erhebung und Nutzung der personenbezogenen Daten, 


e den Zeitraum der Speicherung und Nutzung der personenbezogenen 
Daten, 


e den gegenwärtigen Status der Weitergabe der personenbezogenen Daten 
an Dritte und 


e Angaben über erteilte Einwilligungen. 


Der Status der Weitergabe der personenbezogenen Daten an Dritte umfasst 
auch die Auskunft über die Dritten selbst, also über die Empfänger personen- 
bezogener Daten. Eingeschlossen sind ebenfalls der Zweck der Übermittlung, 
der Zeitraum in dem die Informationen beim Empfänger gespeichert werden 
und die jeweils übermittelten personenbezogenen Daten selbst. 


Ein Anspruch auf Auskunft über die internen Datenflüsse oder die Herkunft 
personenbezogener Daten ist nicht ersichtlich. 


C.3 Abgeleitete Anforderungen an ein 
Datenschutzauskunftssystem 


C.3.1 Vergleich deutscher und koreanischer 
Datenschutzanforderungen 


Wie bereits weiter oben erwähnt, ist das Vertrauensprinzip (Art. 3 Abs. 8 PIPA) 


eine dem koreanischen Datenschutzrecht zugrundeliegende Besonderheit, die 
auf der Ebene der rechtlichen Ziele mit einzufügen ist. 
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Die grundlegenden datenschutzrechtlichen Anforderungen des koreanischen 
Datenschutzrechts unterscheiden sich nicht maßgeblich von den deutschen 
(vgl. Tabelle 4.1). 


Datenvermeidung und Datensparsamkeit finden sich gemeinsam mit der Zweck- 
bestimmung in Art. 3 Abs. 1 PIPA, während Zweckbindung und Zwecktrennung 
separat in Abs. 2 aufgeführt werden. Die anonyme Verarbeitung personenbe- 
zogener Daten und die damit einhergehende anonyme Diensterbringung ist 
ergänzend in Abs. 7 hervorgehoben. Insbesondere soll die Registrierung auf 
Webseiten so erfolgen können, dass die Angabe der RRN nicht erforderlich 
ist (Art. 24 Abs. 2 PIPA). Die Datenkorrektheit ist in Abs. 3 erwähnt und 
wird um die Aspekte Vollständigkeit und Aktualität erweitert. Das koreanische 
Datenschutzrecht hat somit einen umfassenderen Datenqualitätsanspruch als 
das deutsche. 


Die Datensicherheit wird als grundlegende Anforderung in Art. 3 Abs. 4 PIPA 
festgestellt. Die einzelnen Teilaspekte ergeben sich aus Art. 29 PIPA i. V. m. 
Art. 30 des Präsidialen Dekrets. An erster Stelle steht die Aufstellung eines 
internen Managementplans fiir die sichere Verarbeitung personenbezogener 
Daten (Art. 30 Abs. 1 Nr. 1 Präsidiales Dekret). Diese Forderung geht über das 
deutsche Recht hinaus. Zweiter Punkt sind die Zugriffskontrolle und die sichere 
Weitergabe personenbezogener Daten (Art. 30 Abs. 1 Nr. 2 u. 3 Präsidiales 
Dekret). Dabei wird besonderer Wert auf die Verwendung kryptographischer 
Verfahren gelegt. Die revisionssichere Protokollierung ist im dritten Punkt 
explizit verankert und soll die Verfälschung personenbezogener Daten verhin- 
dern (Art. 30 Abs. 1 Nr. 4 Präsidiales Dekret). Eine weitere Besonderheit des 
koreanischen Datenschutzrechts ist die ausdrückliche Forderung der Aktualität 
verwendeter Software im Sinne eines Update-Requirements (Art. 30 Abs. 1 
Nr. 5 Präsidiales Dekret). Die physikalische Zutritts- und Zugangskontrolle 
findet sich im letzten Unterpunkt (Art. 30 Abs. 1 Nr. 6 Präsidiales Dekret). 


Die Einwilligung als wesentliche Voraussetzung der Verarbeitung personenbe- 
zogener Daten ist in Art. 4 Nr. 2 PIPA festgelegt und wird in allen weiteren 
Vorschriften aufgegriffen. Insbesondere in Art. 22 PIPA wird genau geregelt 
nach welchem Verfahren und in Verbindung mit welchen Informationspflichten 
die Einwilligung des Betroffenen einzuholen ist. 
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Eine Regelung entsprechend dem deutschen Verfahrensverzeichnis ist in Art. 3 
Abs. 5 PIPA definiert. Im Detail gehen die Regelungen des Art. 30 PIPA zu den 
Datenschutzrichtlinien deutlich über die deutschen Regelungen hinaus (siehe 
Abschnitt C.2.3). 


Analog zum deutschen Recht ist in Art. 2 Nr. 3 PIPA die verantwortliche Stelle 
definiert. Ein unabhängiger Datenschutzbeauftragter ist in jeder Behörde und 
jedem Unternehmen zu etablieren (siehe Abschnitt C.1.6). 


Aufklärungs-, Unterrichtungs-, Kennzeichnungs-, Hinweis- und Benachrichti- 
gungspflichten finden sich alle auch im koreanischen Recht und wurden bereits 
in Abschnitt C.2.1 und C.2.2 ausführlich diskutiert. Für öffentliche Stellen ist 
in Art. 32 darüber hinaus eine Meldepflicht vorgesehen. Das dem Auskunfts- 
anspruch gleichkommende Einsichtsrecht ergibt sich aus der Kombination des 
Art. 5 Nr. 3 mit Art. 35 PIPA. Die Rechte auf Berichtigung, Löschung und Sper- 
rung personenbezogener Informationen sind in Art. 5 Nr. 4 i. V.m. Art. 36 u. 
37 PIPA verankert. Informationspflichten bei Datenschutzverletzungen werden 
im koreanischen Recht in Art. 43 PIPA beschrieben. 


Die Datenschutzfolgenabschätzung ist, im Gegensatz zum deutschen Recht, 
zumindest für öffentliche Stellen bereits vorgeschrieben (Art. 33 PIPA - siehe 
auch Abschnitt C.1.7). 


Das koreanische Datenschutzrecht kennt zwei wesentliche Bausteine des deut- 
schen Datenschutzrechts nicht: Den Grundsatz der Direkterhebung und das 
Prinzip der nicht-automatisierten Einzelentscheidung. Für beide Fälle steht es 
der verantwortlichen Stelle frei, ihre Prozesse selbst zu gestalten. Auch das 
Datenschutzaudit und die Verfügbarkeitskontrolle werden im koreanischen 
Datenschutzrecht nicht erwähnt. Beide spielen aber auch in Deutschland keine 
besondere Rolle. Das Fehlen von ersterem wird außerdem durch die Daten- 
schutzfolgenabschätzung und die Datenschutzrichtlinien zum Teil aufgefangen. 
Zwei weitere deutsche Rechtsgestalten, das Datengeheimnis und das Wider- 
spruchsrecht, haben ebenfalls keine koreanische Entsprechung. Eine explizite 
organisatorische und technische Gewaltenteilung ist im koreanischen Recht 
nicht vorgesehen. 
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Weder im deutschen noch im koreanischen Datenschutzrecht finden sich die da- 
tenschutzfreundlichen Grundeinstellungen, das Recht auf Datenübertragbarkeit 
und das Recht auf einen einheitlichen Ansprechpartner. Sie sind ausschließlich 
in der DSGVO enthalten. 


C.3.2 Besondere Kriterien für ein 
Datenschutzauskunftssystem 


Wie bereits im Abschnitt C.2.4 dargelegt, ist der wesentliche Unterschied 
zwischen dem deutschen Auskunftsanspruch und dem koreanischen Recht 
auf Einsichtnahme, dass die Beauskunftung von Herkunftsinformationen 
und interne Datenflüsse vom koreanischen Recht nicht gefordert werden. 
Dementsprechend würden in Korea alle darauf basierenden Kriterien entfallen. 


Konkret sind davon die Kriterien 1, 11, 12, 13, 14, 17, 24 und 26 betroffen. Des 
weiteren finden die Sonderfälle der Kriterien 16, 33 und 34 keine Rechtfertigung 
im koreanischen Datenschutzrecht. Die Konkretisierungen der Kriterien 23, 25 
und 29 sind als rein deutsche Vorgaben zu verstehen. 


Auf der anderen Seite wäre ein Datenschutzauskunftssystem mit Sicherheit 
einer Vorabkontrolle zu unterwerfen, um zu überprüfen, ob es nicht selbst zu 
Datenschutzgefährdungen führt. 


Ein ergänzendes Kriterium für Datenschutzauskunftssysteme ist, dass nicht 
nur der Zeitpunkt der Erhebung und Übermittlung personenbezogener Daten 
zu speichern ist, sondern auch die geplante Speicherdauer. Dafür wäre in der 
technischen Umsetzung ein zusätzliches Attribut einzuführen. 


Kriterium K 1. Die geplante Speicherdauer der Verarbeitung und Nutzung 
ist zu speichern und zu beauskunften. 


Eine weitere Besonderheit findet sich im Kontext der Einwilligungen. Ihr 
Bestand ist mit zu beauskunften. Da sich Einwilligungen nicht nur auf einzelne 
personenbezogene Daten beziehen können, sondern auch auf ganze Verar- 
beitungsvorgänge, müsste für Einwilligungen ein ganz eigener Lebenszyklus 
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formuliert werden. Möglicherweise könnten einzelne Einwilligungen sogar in 
Nutzungskontrollvorgaben übersetzt werden. Die daraus entstanden Policies 
wären dann gemeinsam mit den personenbezogenen Daten zu beauskunften. 


Kriterium K 2. Für jedes personenbezogene Datum ist die zugrundeliegende 
Einwilligung für die Speicherung und/oder Verarbeitung mit zu beauskunften. 


Kriterium K 3. Der Bestand der Einwilligungen für gegenwärtige und zu- 
künftige Datenverarbeitungen ist zu beauskunften. 


Kriterium K 4. Bei, auf Grundlage einer Einwilligung erhobenen, perso- 
nenbezogenen Daten, ist automatisiert zu überprüfen, ob eine gewünschte 
Datenverarbeitung durch die gegebene Einwilligung gedeckt ist. 
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Um die Elemente der Datenstrukturen und die Komponenten der gesamten 
UC- und Provenance-Infrastruktur klar unterscheidbar zu machen, müssen 
sie mit einem global eindeutigen Kennzeichen versehen werden. Für solche 
Zwecke wurde der Universally Unique Identifier (UUID) standardisiert und 
etabliert. ! 


Neben den Instanziierungen der Komponenten der UC- und Provenance- 
Architektur? ist bei folgenden Datentypen Eindeutigkeit erforderlich: 


e Container 
e Datum 
e Repräsentation 
e Betroffener 
Daneben sind Policies und (Abstraktions-)Regeln eindeutig zu kennzeichnen. 


In den meisten Fällen finden pseudo-randomisierte Identifikatoren nach UUID 
Version 4 Anwendung. Einzig der Identifikator für ein und denselben Container 
muss zu unterschiedlichen Zeitpunkten von zum Teil unterschiedlichen Kom- 
ponenten unabhängig generiert werden. Ist solch ein Fall abzusehen, werden 
namensbasierte Container-UUIDs gemäß UUID Version 3 angelegt. Als Basis- 
Namensraum wird dabei auf den UCN-Namensraum zurückgegriffen (siehe 
unten). Auf der Ebene eines einzelnen Systems wird ein Container durch die 
ihn verantwortende Abstraktionsschicht, seinen Typ und seinen individuellen 
Namen gekennzeichnet. 


' http://tools.ietf.org/html/rfc4 122. 
2 PEP, PXP, PDP, PRP, PIP, PMP, ProSP, ProCP und ProDP. 
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Usage-Control-Domänen Usage-Control stützt sich mit seinem Unterneh- 
mensfokus auf einen zentralen, hierarchischen Ansatz. Fiir jede Organisation, 
die Usage-Control und Provenance-Tracking einsetzt, wird eine der Organi- 
sation angepasste Domänenhierarchie aufgespannt. Dieser Hierarchie folgen 
das Policy-Management sowie die Verwaltung der UC- und Provenance- 
Komponenten. Domänen sind eindeutige Namen für technische Verantwort- 
lichkeitsstrukturen im Unternehmen. Sie erfordern einen sauber definierten 
Namensraum. 


Der UCN-Namensraum Für die Definition des Namensraums wird auf das 
URN-Schema zurückgegriffen.! Uniform Resource Names (URNS) stellen als 
Teil der Uniform Resource Identifier (URI) einen dauerhaften, ortsunabhängi- 
gen Bezeichner für eine Ressource zur Verfügung.” 


Der Namensraum (Namespace Identifier (NID)) für eine UC-Domäne lautet 
„ucn“ für „Usage Control Node“. 


Die UCN-Syntax sieht wie folgt aus: 


<URN> ::= "urn:ucn:" <Organization> 
<Organization> ::= 1*<let-num-hyp> | 
1*<let-num-hyp> ":" <OrgUnit> | 
1*<let-num-hyp> ":" <SystemType> | 
1*<let-num-hyp> ":" <IT-System> 
<OrgUnit> ::= 1*<let-num-hyp> | 
1*<let-num-hyp> ":" <OrgUnit> | 
1*<let-num-hyp> ":" <SystemType> | 
1*<let-num-hyp> ":" <IT-System> 


U http://tools.ietf.org/html/rfc2141. 
2 http://tools.ietf.org/html/rfc3986. 
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<SystemType> ::= 1*<let-num-hyp> | 
1*<let-num-hyp> ":" <SystemType> | 
1*<let-num-hyp> ":" <IT-System> 
<IT-System> ::= 1*<let-num-hyp> 


Wobei <let-num-hyp> dem „Namespace Specific String Syntax“ aus RFC 2141 
Abschnitt 2.2 entspricht: ! 


<let-num-hyp> ::= <upper> | <lower> | <number> | "-" 


<upper> = "A" | "B" | "C" | "D" | "E" | "F" | "G" ] 
"E" p "I" j "g" J "RY | "L" | "M" | "N" | 
"O" | "P" | "gh | "R" | "S" | "T" | "U" | 
"yn jong" | "g" j "yg" j o"z" 

<lower> p= ta" | "p" | te" | "d" | "e" | "£" | "g" | 
je ee a | 
"o" | "pr | "q" | "rn | "s" | "t" | "u" | 
"y" | o"w" | "x" | "y" | "z" 

<number> z= "o" j o"a" p "2" j "3" | "4" | "5" | "6" ] 
"g" jng" | "9" 


Der Namensraum ist hierarchisch (Baumstruktur). Jeder Teilpfad mit dem 
eine UC-Domäne beginnt, ist immer selbst auch eine gültige UC-Domäne 
und der ursprünglichen UC-Domäne übergeordnet. Die unterste Ebene des 
Namensraums wird als lokale Domäne bezeichnet. 


Beispiel. Ein gültiger Domänenname für ein Android- 
Testgerät der Vertriebsabteilung von AdBokis wäre 
urn:ucn:adbokis:sales:android-mobile-device:nexus1l0-testl. 


1 http://tools.ietf.org/html/rfc2 141. 
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E.1 XML-Schema der 
Informationsflusssemantik 


Das folgende Listing zeigt die XML-Schema-Definition der Informationsfluss- 


semantik. 


<?xml version="1.0" encoding="UTF—8"?> 

<xs:schema 
xmins:xs="http:/Awww.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<xs:element name="ifsemantics"> 
<xs:complexType> 
<xs:sequence> 
<xs:element ref="params"/> 
<xs:element ref="actions"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 


<xs:element name="params"> 
<xs:complexType> 
<xs:sequence> 
<xs:element maxOccurs="unbounded" ref="param"/> 
</xs:sequence> 
</xs:complexType> 
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</xs:element> 


<xs:element name="param"> 
<xs:complexType> 
<xsiattribute ref="name" use="required"/> 
<xs:attribute ref="type" use="required"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="actions"> 
<xs:complexType> 
<xs:sequence> 
<xs:element maxOccurs="unbounded" ref="action"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 


<xs:element name="action"> 
<xs:complexType> 
<xs:sequence> 
<xs:element minOccurs="0" maxOccurs="unbounded" 
— ref="scope"/> 
<xs:element maxOccurs="unbounded" ref="operation"/> 
</xs:sequence> 
<xs:attribute ref="name" use="required"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="scope"> 
<xs:complexType> 
<xs:simpleContent> 
<xs:extension base="xs:string"> 
<xs:attribute ref="behavior" default="INTRA"/> 
<xs:attribute ref="delimiter" default="NONE"/> 
<xs:attribute ref="interSystem" default="FALSE"/> 
</xs:extension> 
</xs:simpleContent> 
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</xs:complexType> 
</xs:element> 


<xs:element name="operation"> 
<xs:complexType> 
<xs:sequence> 
<xs:element ref="left"/> 
<xs:element ref="right"/> 
</xs:sequence> 
<xs:attribute ref="name" use="required"/> 
</xs:complexType> 
</xs:element> 


<xs:element name="left"> 
<xs:complexType> 
<xs:sequence> 


<xs:element minOccurs="1" maxOccurs="1" ref="operand"/> 


</xs:sequence> 
</xs:complexType> 
</xs:element> 


<xs:element name="right"> 
<xs:complexType> 
<xsisequence> 


<xs:element minOccurs="0" maxOccurs="unbounded" 


= ref="operand"/> 
</xs:sequence> 
</xs:complexType> 
</xs:element> 


<xs:element name="operand" type="xs:NCName"/> 
<xsiattribute name="type" type="xs:NCName"/> 
<xs:attribute name="name" type="xs!NCName"/> 
<xs:attribute name="behavior" type="behaviors"/> 
<xs:attribute name="delimiter" type="delimiters"/> 
<xs:attribute name="interSystem" type="boolean"/> 
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<xs:simpleType name="behaviors"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="IN"/> 
<xs:enumeration value="OUT"/> 
<xs:enumeration value="INTRA"/> 
</xs:restriction> 
</xs:simpleType> 


<xs:simpleType name="delimiters"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="OPEN"/> 
<xs:enumeration value="CLOSE"/> 
<xs:enumeration value="NONE"/> 
</xs:restriction> 
</xs:simpleType> 


<xs:simpleType name="boolean"> 
<xs:restriction base="xs:string"> 
<xs:enumeration value="TRUE"/> 
<xs:enumeration value="FALSE"/> 
</xs:restriction> 
</xs:simpleType> 
</xs:schema> 
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E.2 XML-Schema eines Events 


Die folgende XML-Schema-Definition zeigt die Syntax eines Events. 


<?xml version="1.0" encoding="UTF—8"?> 

<schema 
xmins = "http://www.w3.0rg/2001/XMLSchema" 
targetNamespace = "http://www.iosb.fhg.de/duc/1.0/event" 
xmins:tns = "http://www.iosb.fhg.de/duc/1.0/event" 
elementFormDefault = "qualified"> 


<complexType name="EventParameterType"> 
<attribute name="name" type="string" use="required" /> 
<attribute name="value" type="string" use="required" /> 
<attribute name="type" type="tns:EventParameterDataTypes" 
— default="string"/> 
</complexType> 


<simpleType name="EventParameterDataTypes"> 
<restriction base="string"> 
<enumeration value="string" /> 
<enumeration value="binary" /> 
<enumeration value="int" /> 
<enumeration value="long" /> 
<enumeration value="bool" /> 
<enumeration value="stringArray" /> 
</restriction> 
</simpleType> 


<attributeGroup name="SimpleEventParameterAttributes"> 
<attribute name="name" type="string" use="required" /> 
<attribute name="value" type="string" use="required" /> 
<attribute name="type" type="tns:EventParameterDataTypes" 
<> default="string"/> 
</attributeGroup> 


<complexType name="ComplexEventParameterType"> 
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<choice maxOccurs="unbounded"> 
<element name="complexParameter" 
— type="tns:ComplexEventParameterType" minOccurs="0" 
—> maxOccurs="unbounded" /> 
<element name="parameter" type="tns:EventParameterType" 
< + minOccurs="0" maxOccurs="unbounded" /> 
</choice> 
<attribute name="name" type="string" use="required" /> 
</complexType> 


<complexType name="EventType"> 
<choice maxOccurs="unbounded"> 
<element name="complexParameter" 
<> type="tns:ComplexEventParameterType" minOccurs="0" 
— maxOccurs="unbounded" /> 
<element name="parameter" type="tns:EventParameterType" 
= minOccurs="0" maxOccurs="unbounded" /> 
</choice> 
<attribute name="action" type="string" /> 
<attribute name="timestamp" type="tns:Timestamp Type" /> 
<attribute names"isTry" type="boolean" default="false" /> 
<attribute name="signallerComponent" type="string" /> 
<attribute name="subject" type="string" /> 
<attribute name="target" type="string" /> 
</complexType> 


<simpleType name="ParamMatchDataTypes"> 
<restriction base="string"> 
<pattern value="string|dataUsage|xpath|regex|binary|int|long| 
— boollstringArray|context'/> 
</restriction> 
</simpleType> 


<complexType name="ParamMatchType"> 
<attribute name="name" type="string" use="required" /> 
<attribute names"value" type="string" use="required" /> 
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<attribute name="type" type="tns:ParamMatchDataTypes" 
— default="string"/> 
<attribute name="negate" type="boolean" use="optional" 
— default="false" /> 
</complexType> 


<complexType name="EventMatchingOperatorType"> 
<sequence> 
<element name="paramMatch" type="tns:ParamMatchType" 
= minOccurs="0" maxOccurs="unbounded" /> 
</sequence> 
<attribute name="action" type="string"/> 
<attribute name="class" type="tns:ActionClassType"/> 
<attribute name="isTry" type="boolean" default="false"/> 
</complexType> 


<simpleType name="ActionClassType"> 
<restriction base="string"> 
<enumeration value="USAGE"/> 
<enumeration value="SIGNALLING"/> 
<enumeration value="OTHER"/> 
</restriction> 
</simpleType> 


<simpleType name="TimestampType"> 
<restriction base="dateTime"/> 
</simpleType> 


<element name="event" type="tns:EventType"/> 
</schema> 
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E.3 Erweiterung von Event-Deklarationen 


Um verschachtelte Parameter in Events zuzulassen, muss die OSL-Syntax 
von Hilty et al. leicht erweitert werden.! Die notwendige Erweiterung wird 
im Folgenden in der auf Z basierenden Syntax von OSL formuliert. In der 
ursprünglichen Form besteht ein Event aus einem Eventnamen und Parametern, 
die durch eine partielle Funktion (+) von Parameternamen auf Parameterwerte 
repräsentiert werden. Für verschachtelte Parameter wird die partielle Funktion 
Params wie folgt definiert: 


[EventName, ParamName, ParamV alue] 

EventClass == {usage, signalling, other} 

getclass : EventName — EventClass (E.1) 
Params : ParamName + (Params U ParamValue) 


Event == EventName x Params 


Eine Eventdeklaration spezifiziert die Events, die in einem konkreten System 
beobachtet werden können. Die Eventdeklaration wird modifiziert wie folgt 
definiert: 


EventDecl == EventName x EventClass x ParamDecl 


(E.2) 


ParamDecl : ParamName + P (ParamDecl U ParamValue) 


E.4 Auszug aus der Informationsflusssemantik 
des Windows-PEP 


<?xml version="1.0" encoding="UTF—8"?> 
<ifsemantic> 
<params> 
<param name="process" type="CONTAINER" /> 


! Hilty et al. 2007. 
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<param name="file" tyoe="CONTAINER" /> 


<param name="process_name" type="DESIGNATOR" /> 
<param name="InFileName" type="DESIGNATOR" /> 


</params> 
<actions> 
<action name="CreateProcess"> 
<operation name="NF_ADD_NAMING"> 
<left> 
<operand>process_name</operand> 
</left> 
<right> 
<operand>process</operand> 
</right> 
</operation> 
</action> 
<action name="KillProcess"> 
<operation name="SF_CLEAR"> 
<left> 
<operand>process_name</operand> 
</left> 
<right></right> 
</operation> 
<operation name="AF_CLEAR_ALIASES"> 
<left> 
<operand>process_name</operand> 
</left> 
<right></right> 
</operation> 
<operation name="NF_RM_NAMING"> 
<left> 
<operand>process_name</operand> 
</left> 
<right></right> 
</operation> 
</action> 
<action name="CreateFile"> 
<operation name="NF_ADD_NAMING"> 
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<left> 
<operand>InFileName</operand> 
</left> 
<right> 
<operand>file</operand> 
</right> 
</operation> 
</action> 
<action name="ReadFile"> 
<operation name="SF_FLOW_TO_RTC"> 
<left> 
<operand>process_name</operand> 
</left> 
<right> 
<operand>InFileName</operand> 
</right> 
</operation> 
</action> 
<action name="WriteFile"> 
<operation name="SF_FLOW_TO_RTC"> 
<left> 
<operand>InFileName</operand> 
</left> 
<right> 
<operand>process_name</operand> 
</right> 
</operation> 
</action> 
</actions> 
</ifsemantic> 
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E.5 Im Beispiel zu systemübergreifenden 


Informationsflüssen verwendete 
Informationsflusssemantiken 


<?xml version="1.0" encoding="UTF—8"?> 
<ifsemantic> 
<params> 
<param name="network" type="CONTAINER" /> 


</params> 
<actions> 
<action name="downloadFile_start"> 
<scope behavior="OUT" delimiter="OPEN" 
— intersystem="TRUE">URL</scope> 
<scope behavior="INTRA" /> 
<operation name="NF_ADD_NAMING"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> 
<operand>network</operand> 
</right> 
</operation> 
<operation name="SF_FLOW"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> 
<operand>applicationObject_name</operand> 
</right> 
</operation> 
</action> 
<action name="downloadFile_end"> 
<scope behavior="OUT" delimiter="CLOSE" 
— intersystem="TRUE">URL</scope> 


<param name="network_name" type="DESIGNATOR" /> 
<param name="applicationObject_name" type="DESIGNATOR" /> 
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<scope behavior="INTRA" /> 
<operation name="SF_CLEAR"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> </right> 
</operation> 
<operation name="NF_RM_NAMING"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> </right> 
</operation> 
</actions> 
</ifsemantic> 


Listing E.1: Informationsflusssemantik von Shopware 


<?xml version="1.0" encoding="UTF—8"?> 
<ifsemantic> 
<params> 
<param name="network" type="CONTAINER" /> 
<param name="network_name" type="DESIGNATOR" /> 
<param name="applicationObject_name" type="DESIGNATOR" /> 
</params> 
<actions> 
<action name="downloadFile_start"> 
<scope behavior="OUT" delimiter="OPEN" 
— intersystem="FALSE">URL</scope> 
<scope behavior="OUT" delimiter="NONE" 
— intersystem="FALSE">URL</scope> 
<scope behavior="INTRA" /> 
<operation name="NF_ADD_NAMING"> 
<left> 
<operand>network_name</operand> 
</left> 
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<right> 
<operand>network</operand> 
</right> 
</operation> 
<operation name="SF_FLOW"> 
<left> 
<operand>applicationObject_name</operand> 
</left> 
<right> 
<operand>network_name</operand> 
</right> 
</operation> 
</action> 
<action name="downloadFile_end"> 
<scope behavior="OUT" delimiter="CLOSE" 
— intersystem="FALSE">URL</scope> 
<scope behavior="INTRA" /> 
<operation name="SF_CLEAR"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> </right> 
</operation> 
<operation name="NF_RM_NAMING"> 
<left> 
<operand>network_name</operand> 
</left> 
<right> </right> 
</operation> 
</action> 
</actions> 
</ifsemantic> 


Listing E.2: Remote-Informationsflusssemantik von Shopware 
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<?xml version="1.0" encoding="UTF—8"?> 
<ifsemantic> 
<params> 
<param name="webRessource" type="CONTAINER" /> 
<param name="downloadltem" type="CONTAINER" /> 
<param name="downloadltemID" type="DESIGNATOR" /> 
<param name="filename" type="DESIGNATOR" /> 
</params> 
<actions> 
<action name="onCreated"> 
<scope behavior="IN" delimiter="OPEN">url</scope> 
<scope behavior="IN" delimiter="NONE">url</scope> 
<operation name="SF_FLOW"> 
<left> 
<operand>downloaditem</operand> 
</left> 
<right> 
<operand>webRessource</operand> 
</right> 
</operation> 
<operation name="NF_ADD_NAMING"> 
<left> 
<operand>downloadlitemID</operand> 
</left> 
<right> 
<operand>downloaditem</operand> 
</right> 
</operation> 
</action> 
<action name="onChanged"> 
<scope behavior="IN" delimiter="NONE">url</scope> 
<operation name="SF_FLOW"> 
<left> 
<operand>downloaditemID</operand> 
</left> 
<right> 
<operand>webRessource</operand> 
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</right> 
</operation> 
</action> 
<action name="onClose"> 
<scope behavior="INTRA"></scope> 
<operation name="SF_FLOW"> 
<left> 
<operand>filename</operand> 
</left> 
<right> 
<operand>downloadltemID</operand> 
</right> 
</operation> 
<operation name="SF_CLEAR"> 
<left> 
<operand>downloadltem|ID</operand> 
</left> 
<right> 
</right> 
</operation> 
<operation name="NF_RM_NAMING"> 
<left> 
<operand>downloadltem|ID</operand> 
</left> 
<right> 
</right> 
</operation> 
</action> 
</actions> 
</ifsemantic> 


Listing E.3: Informationsflusssemantik des Chrome-Download-Managers 
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F Beweise und Definitionen zur 
Unverkettbarkeit 


F.1 Verkettungsrelationen 


F.1.1 Relationenprodukt 


Mit Hilfe des Relationenproduktes lassen sich zweistellige Relationen zu 
mehrstelligen Relationen verknüpfen. 


Mehrstelliges Relationenprodukt Seien RC A, x... x Aj und S C 
Aj41 x... X A, zwei Relationen (mit 1 < j < n). 


Definition F.1. Dann ist das a-Produkt (mit 1 < a < max{j,n — j}) von R 
und S definiert als die Relation 


R Oa S:= (aa+1,-.-;4j, datj+1y-- - Am) 
E Ansa X- X Åj Z RA | 
da, € AAN Aj... Jaa € Áa N Aa+; : 


(see 
(a1,. 


9 ors Qatj+1, +++) On) € S} 


Zweistelliges Relationenprodukt Für ein zweistelliges Relationenprodukt 
R©S der Relationen R C A; x As und S C A3 x A4 werden mehrere 
Kurzschreibweisen verwendet. Zunächst, das (a, 3)-Produkt (mit a € {1,2} A 


B € {3,4}): 
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Definition F.2. 


Rag S= 
{(a2,a4) € Ag x A4 | Ja € AVN A3 : (a,a2) E RA (a,aı) € S} 
fira=1AB=3 
{(ag,a3) € Ag x Az Ja € AıN A4 : (a,a2) E RA (as,a) € S} 
füra=1^p=4 


{(a1, a4) € Ay x Ag | Ja € A2 N Az: (a1,a) E RA (a, a4) € S} 
füra=218=3 


{(a1, a3) € Aı x As Ja € A2 N Aq: (a1,a) E RA (as,a) € S} 
fira=2AB=4 


Häufig kommt es vor, dass das Relationenprodukt aus zwei zweistelligen 
Relationen mit zwei gemeinsamen Bereichen und drei disjunkten Mengen 
gebildet werden soll. Der gemeinsame Bereich M wird als Mittler bezeichnet. 


Definition F.3. Das Relationenprodukt von S C A x M undT C Bx M 
(mit ANB=PAANM =0A BOM =) wird kurz als 


Ry =S OmT:=8204T 


geschrieben (analog fiir die Kombinationen mit S~ und T~?). 


F.1.2 Mehrstellige Verkettungsrelationen und Anonymität 


Verkettungsrelationen mit mehr als zwei Stellen werden verwendet, wenn 
Entitäten Mittler zur Verkettung anderer Entitäten sind. Die Verkettung von 
Quasi-Identifikatoren mit einem sensitiven Attribut in einer Datenbank ist solch 
ein Fall. Die Quasi-Identifikatoren fungieren als Mittler zwischen Subjekt und 
sensitivem Attribut RC Q1 X ++: X Qn X A. 
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Verkettungsrelationen mit Quasi-Identifikatoren Q; und einem sensitiven 
Attribut A können auf zweistellige Relationen reduziert werden, wenn das 
n-Produkt S ©, R aus der Verkettungsrelation zwischen Quasi-Identifikatoren 
und Subjektidentifikator S C Qı x--- X Qn x ID und der Verkettungsrelation 
RC Qı X- X Qn x A gebildet wird. 


Anhand dieser Überlegungen wird deutlich, dass sich Anonymität nach der hier 
vorgenommenen Definition als ein Sonderfall der Unverkettbarkeit betrachten 
lässt. Der Begriff der Anonymität findet auf Verkettungsrelationen Anwendung, 
die Identifikatoren als Entitäten enthalten. Solche Verkettungsrelationen werden 
in dieser Arbeit als Identifikationsrelationen bezeichnet. 


Entsprechend der Vielfalt der Definitionen in der Literatur, werden Unverkett- 
barkeit und Anonymität allerdings als technisch gleich, ! unterschiedlich? oder 
unabhängig? aufgefasst. 


F.1.3 Äquivalenzklassen homogener Verkettungsrelationen 


Aus jeder zweistelligen Verkettungsrelation R C A x B lassen sich die beiden 
homogenen Relationen R4 und Rpg ableiten. 


Definition F.4. 


Ra := {(b1,b2) € Bx B| dae A: (a,b1) € RA (a,b2) € R} 
Rp := {(a1,a2) € AX A| 4b € B: (a1,b) E€ RA (a2,b) € R} 


Der jeweils andere Bereich fungiert als Mittler fiir die Bildung der homogenen 
Relation. 


l Bellare/Micciancio/Warinschi 2003. 
2 Hevia/Micciancio 2008; Pashalidis 2008; Bohli/Pashalidis 2011. 
3 Hughes/Shmatikov 2004. 
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Lemma F.5. Sei RC A x B eine Verkettungsfunktion (linkstotal, rechts- 
eindeutig). Dann ist Rg eine Aquivalenzrelation und teilt A in disjunkte 
Aquivalenzklassen. 


Beweis. Eine Relation ist eine Aquivalenzrelation, wenn sie reflexiv, symme- 
trisch und transitiv ist. 
Die Reflexivität von Rpg ergibt sich aus der Linkstotalität von R: 


Vac AVE B: (a,b) eR => (aa) € Rg 


Die Symmetrie lässt sich aus der Definition von Rpg herleiten: 


Vaı, a2 € A,(a1,a2) E€ Rp IDE B: (a1,b) E RA (a2,b) E€ R 
=> (a2,b) E€ RA (a1,b) E R > (a2,a1) € Rg 


Die Transitivität ergibt sich aus der Rechtseindeutigkeit von R: 


Vaı,a2,a3 € A, (a1,a2) € Rg A (a2,a3) € Rp Ib, E BAbo EB: 
(a1, 61) E RA (a2, 61) E RA (a2, b2) € RA (a3,b2) E R 

und aus der Rechtseindeutigkeit von R folgt 

Va € A Vbı,b2 E€ B : (a,b1) E RA (a,b2) E R => bi = bg 

Da nun bı = by => (a, b1) E RA (az,b1) E R => (aı,a3) € Rg 


Ist R bijektiv so ist auch R4 eine Äquivalenzrelation. 


Beispiel. Sofern ein personenbezogenes Datum d € Q genau einem Betrof- 
fenen b € & zugeordnet werden kann (kein mehrfacher Personenbezug), 
ist die Identifikationsrelation RS C 2 x  rechtseindeutig und linkstotal. 
Rg = R= ist eine Äquivalenzrelation auf der Menge aller personenbezogenen 
Daten. 
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Beispiel. Alle Zuordnungstabellen für (subjekteindeutige) Pseudonyme sind 
Funktionen. Die wahren Identitäten der Subjekte bilden eine Äquivalenzrelation 
auf der Menge der Pseudonyme der Tabelle. 


F.2 Additivität der Entropie 


Die Entropie ist eine additive Größe. Es gilt H(X”) = H(X) +- + 
H(XẸ ). 


Beweis. 
H(X®) 
=- >> P(X” = R”)log, P(X” = R>) 
R> ER> 
= - 5 P(X? = RẸ un = RẸ ) 


RG, ERG, RG, ERG, 
log, P(XZ, = Rj,,--.,X¢, = RZ) 
= > P(XG, = Ra) POXZ, = Ra.) 
RG, ERG RG, ERG, 
logs P(Xz, = RG, ) .. :P(XZ, = RG) 


= 5 P(X? = RẸ) P(XÈ = RẸ ) 


(logy P(XZ, = Ri.) +- + loga P(XZ, = RẸ,)) 
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nn 5 P(X? = RẸ) PAR, = RẸ ) 
RI, ERG RG, ERG, 
(log: PX, = R) - 
— 5 P(X? = R3) P(XẸ = RẸ ) 
RE, ERG RG, ERG, 


(log, P(XZ, = Ra, )) 


=- J PUG = FG) oo Jo POG, = Bi) 
RE, ERG RZ ERG, 
>, P(XG, = Ri, (log: P(XG, = RG.) — 
RI ERG, 
= DP PAR =RR) DD PCE = Ri) 
REL ERG, R ERD, 


(log, P(XZ, = Ra, )) 


= — 5 P(XẸ = RẸ (logs P(X? = R? )) Zee 
RG, ERG, 
- So P(X = RF )(log, P(XF = RF )) 
RẸ ERT, 


=H XG.) 


F.3 Ableitung des Provenance-Systemmodells 
aus dem Provenance-Datenmodell 


Ein Provenance-System-Graph 9° = (.%, Y™, col) ist ein kantengefärbter, 
gerichteter Graph mit den Knoten (Systemen) Z, den Kanten Z? C Z x S 
und der Färbung col : Z? —> P(9). 
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F3 Ableitung des Provenance-Systemmodells 


Ein System vereint alle Repräsentationen, deren Container mit derselben 
Domäne bezeichnet wird. Lokale Domänen sind Bezeichner für Systeme. 
Die Abbildung von Repräsentationen auf Systeme ist durch die Funktion 
loc: Z — SF gegeben. Die Zuordnung der Systeme zu Repräsentationen 
durch die Funktion loc ist äquivalent mit der Zuordnung der Domäne zu einem 
Container durch die Umkehrfunktion der Benennungsfunktion fpom: 


Ypı = (d1,¢1,t1), p2 = (d2,C2,t2) E€ Z : 


F pov (C1) = fDom(€2) o loc(p1) = loc(p2) 


Die Kanten ergeben sich aus dem ursprünglichen Provenance-Graph %. Sie ver- 
binden Systeme abhängig von den Kanten .Z£ zwischen den Repräsentationen, 
die auf die Systeme abgebildet werden. Die Kantenfärbung col : Z? — P(9) 
erhält die Information, welche Daten von einem System in ein anderes geflossen 
sind. Diese Information ist im Provenance-Graph nicht in den Kanten, sondern 
in den Repräsentationen, also den Knoten, hinterlegt. 


Die Kanten und die Färbung des Provenance-System-Graphen Z? C S x S 
leiten sich wie folgt aus dem Provenance-Graphen ab: 
Vi, E F Yd E BV pi = (d,c1,t1), p2 = (d,C2,t2) E€ Z : 


loc(pı) = sı A loc(p2) = S2 A (p1, p2) € Z 
— (61,0) € Z? AdE col(s1, s2) 


VS, S2 E F 3p1, p2 E Z: 
(S1; S2) € Pras loc(pı) = 61 A loc(p2) = <2 A (p1, p2) € Z 
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G Ablauf, Aufgaben und Fragebögen 
der Nutzerstudie 


In den folgenden drei Abschnitten werden die Vorgaben zum Versuchsablauf 
(Abschnitt G.1), die Aufgaben (Abschnitt G.2) und die Fragebögen (Ab- 
schnitt G.3) wörtlich wiedergegeben. In der Studie wurde PrivacyInsight als 
„Privacy Dashboard“ und GenomSynlig kurz als „Synlig“ bezeichnet. 


G.1 Ablaufprotokoll 


(Regieanweisungen sind blau hervorgehoben) 
Tabs offen, Synlig gefiltert, PDF offen 
Testkandidat sitzt am Survey-Schreibtisch. 


Datenschutzerklärung aushändigen und ausfüllen lassen 


Optional mündlich erläutern 


Im Rahmen dieser Studie erfassen wir 


1. den Zeitbedarf für die Aufgabenstellungen im Versuchsablauf, 
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2. die Antworten zu den Aufgaben im Versuchsablauf, 


3. die Bewertungen und demografische Daten entsprechend des Versuchs- 
fragebogens, 


4. die Trackingdaten des Blickverhaltens im Versuch 


5. und Kommentare des Versuchsteilnehmers zum Versuchsablauf und zum 
Versuchsobjekt. 


Die Teilnehmerliste wird getrennt von den Versuchsdaten aufbewahrt. Da 
dennoch eine Zuordnung ihrer Daten über den Zeitstempel möglich wäre, 
gelten die Daten als pseudonym erhoben. Nach Ende der Studie, jedoch 
spätestens nach einem Monat, werden die Teilnehmerliste und die Zeitstempel 
gelöscht. 


Die Daten werden nur anonym ausgewertet. 


Bitte füllen Sie als erstes die Datenschutzerklärung für diesen Versuch aus. 


Tobii-Aufzeichnung wird gestartet 


Testkandidat an den PC bitten 


Testkandidat sitzt vor dem PC, interagiert aber nicht mit diesem. 


Fassen Sie bitte Maus oder Tastatur nicht an, außer Sie werden dazu 
aufgefordert. Bitte betätigen Sie niemals die ESC-Taste. 


Ich werde Ihnen jetzt eine Einführung in das Szenario geben. 
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G.1 Ablaufprotokoll 


Nach § 34 Abs. 1 Satz 1 BDSG hat die verantwortliche Stelle dem Betroffenen 
auf Verlangen Auskunft tiber die zu seiner Person gespeicherten Daten, deren 
Herkunft, mögliche Empfänger und den Zweck der Speicherung zu erteilen. 
Um dem Nutzer die Möglichkeit zu bieten sein Auskunftsrecht online wahrzu- 
nehmen gibt es unterschiedliche Systeme und Darstellungsmöglichkeiten. 


Im Rahmen der Evaluation nehmen Sie die Rolle des Betroffenen im 
Sinne des Datenschutzes ein. Sie haben auf Empfehlung eines Freundes 
beim Onlineshop AdBokis Buchclub GmbH eingekauft und sich dafür ein 
Benutzerkonto angelegt. Zwei Tage später erhalten Sie einen Newsletter per 
Mail der Firma Extreme Advertisement Ltd. Sie möchten jetzt wissen wie 
Ihre Daten an das Unternehmen gekommen sind. Da Sie von der Extre- 
me Advertisement Ltd. keine Antwort erhalten erkundigen Sie sich bei AdBokis. 


Wir schauen uns jetzt nacheinander drei unterschiedliche Darstellungsmöglich- 
keiten für Datenschutzauskünfte an. Es gibt 5 Aufgaben die unter Zeitnahme 
für jede Darstellungsmöglichkeit gelöst werden müssen. Beantworten Sie die 
Fragen zügig, nach den Fragen haben Sie noch Zeit sich das System genauer 
anzuschauen. Nach dem Lösen der Aufgaben muss jeweils noch ein kurzer 
Usability-Fragebogen ausgefüllt werden, bevor mit der nächsten Darstellungs- 
möglichkeit angefangen werden kann. 


Je System wiederholen 


Sie sehen auf dem Bildschirm gerade die erste/zweite/dritte Darstellungsvari- 
ante. 
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Die Darstellungsvariante wird von der AdBokis Buchclub GmbH / einem 
Dienstleister auf ihrer/seiner Webseite zur Verfügung gestellt. 


In dieser Variante sind Sie die/der Betroffene Alice Fox / Bob Bobsson. 


Ich werde jetzt Aufgaben vorlesen, die Sie bitte zu lösen versuchen. Ich werde 
Sie nach jeder Aufgabe fragen, ob Sie sie verstanden haben. Bitte beginnen Sie 
erst, wenn ich Ihnen sage, dass Sie jetzt beginnen dürfen und fassen Maus oder 
Tastatur vorher bitte nicht an. Ab dann haben Sie zwei Minuten Zeit, um die 
Aufgabe zu lösen. Wenn Sie eine Lösung gefunden haben, lassen Sie bitte 
Maus und Tastatur wieder los und teilen mir dies mit. Ich stoppe dann die Zeit. 
Sie haben Papier und Stift vor sich liegen und können sich Notizen machen. 
Haben Sie erstmal mit der Auflösung begonnen, dürfen Sie nicht mehr mit 
dem PC interagieren. 


Haben Sie die Anweisungen verstanden? 


Beginnen wir mit der ersten Aufgabe (-— Sie dürfen jetzt wieder an den PC). 


Je Aufgabe wiederholen 


Aufgabe vorlesen 


Haben Sie die Aufgabe verstanden? 


Wenn nein, wiederholen/erklären, wenn ja weiter 
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Dann diirfen Sie beginnen. 


Sie haben jetzt noch eine Minute Zeit sich ohne Zielvorgabe mit dem System 
vertraut zu machen. 


Minute warten lassen. 


Bitte wechseln Sie den Arbeitsplatz. Wir haben fiir dieses System einen System 
Usability Survey vorbereitet. 


SUS aushändigen und ausfüllen lassen 


Im zweiten Abschnitt wollen wir uns jetzt eine der Darstellungsvarianten 
genauer anschauen. Hierfür gibt es zuerst eine kurze Einführung und dann 
10 Aufgaben. Danach gibt es noch kurz die Möglichkeit sich das System 
frei anzuschauen und dann erneut einen kurzen Usability-Fragebogen. 
Abschließend werden noch generelle Fragen gestellt und demographische 
Daten erhoben. Bitte fassen Sie während der folgenden Erklärung die Maus 
oder Tastatur nicht an. Wir führen die folgenden Dinge nicht vor, Sie können 
Sie gerne während der folgenden Aufgaben ausprobieren. 


Erklärung Interaktionsicons aushändigen 


In der oberen Leiste finden Sie auf der rechten Seite allgemeine Interaktions- 
möglichkeiten. Von links nach rechts sind das: die Option einen Schritt zurück 
zu gehen, den Graphen auf seine Ursprungszustand zurückzusetzen, Ihre Daten 
zu exportieren und abschließend sich abzumelden. 


427 


G Ablauf, Aufgaben und Fragebögen der Nutzerstudie 


Zentral finden sie den Fluss Ihrer Daten durch das Unternehmen in Graphen- 
form. Jeder Kreis stellt dabei eine Organisationseinheit oder ein IT-System 
dar. Orangene Kreise lassen sich durch einfaches Klicken in enthaltene Un- 
tereinheiten aufteilen und damit genauer Analysieren. Die grauen Kreise am 
linken Rand stellen die Informationsquellen dar, die grauen Kreise am rechten 
Rand die Informationssenken. Die blauen Grafiken neben Quellen und Senken 
stellen die erhobenen, bzw. übermittelten, personenbezogenen Daten dar - 
durch einfaches klicken auf die blauen Grafiken wird der zurückgelegte Pfad 
bzw. Datenfluss im Graphen hervorgehoben. 


Beim Bewegen der Maus über Knoten oder Datensätze offenbaren diese ihren 
Namen und bieten mit Klick auf die orangenen Symbole die Möglichkeit 
weitere Details zur Datenverarbeitung zu erfahren (LUPE), einen Knoten 
Aufzuklappen (DOPPELPFEIL) oder in den Datensatz hineinzuschauen (AU- 
GE) und diesen herunterzuladen (DOWNLOAD), zu bearbeiten (STIFT), zu 
löschen (MÜLLEIMER) und die Adbokis Buchclub GmbH zu kontaktieren 
(BRIEFUMSCHLAG). 


Doppelklick und Rechtsklick haben keine Funktion, das gesamte Privacy 
Dashboard lässt sich, wie im Web üblich, mit einfachen Linksklicks bedienen. 


Haben Sie noch Fragen? 


Fangen wir mit den Aufgaben an. 


Je Aufgabe wiederholen 


Aufgabe vorlesen 


Haben Sie die Aufgabe verstanden? 
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Wenn nein, wiederholen/erklären, wenn ja weiter 


Dann diirfen Sie beginnen. 


Wiederholen bis alle Aufgaben abgearbeitet sind 


Sie haben jetzt noch zwei Minuten Zeit sich ohne Zielvorgabe mit dem System 
vertraut zu machen. 


Zwei Minuten warten lassen. 


Bitte wechseln Sie den Arbeitsplatz. 


Wir haben auch fiir diese Runde einen System Usability Survey vorbereitet. 


Außerdem noch 3 weitere Fragebögen, die wir Ihnen anschließend aushändigen. 


SUS aushändigen und ausfüllen lassen 


Als zweites den User Experience Questionnaire. Auch dieser Fragebogen 
bezieht sich ausschließlich auf die Darstellungsvariante, die sie zuletzt gesehen 
haben. 


UEQ aushändigen und ausfüllen lassen 


Und als drittes einige ergänzende Fragen. 


429 


G Ablauf, Aufgaben und Fragebögen der Nutzerstudie 


„Privacy Dashboard“ in Frage 2 bezeichnet die Darstellungsvariante, die 
Sie zuletzt gesehen haben. „Synlig“ bezeichnet die Darstellungsvariante, in 
der Sie Bob Bobsson waren. In Frage 4 wählen sie bitte nur eine Antwort 
aus. Die oberen Antwortmöglichkeiten werden durch die darunterliegenden 
eingeschlossen. (Mit Ausnahme der letzten beiden Antwortmöglichkeiten) 


Erweiterte Fragen aushändigen und ausfüllen lassen 
Zuletzt einen Fragebogen für demografische Daten. 
Demografische Daten ausfüllen lassen. 


Vielen Dank für die Teilnahme an unserer Evaluation! 


G.2 Aufgaben 


Aufgaben im ersten Teil 


1. Finden Sie heraus, ob die Adbokis Buchclub GmbH in der Vergangenheit 
ein Bild von Ihnen bekommen hat. 


2. Finden Sie heraus, welche e-Mailadresse bei der Adbokis Buchclub 
GmbH von Ihnen hinterlegt ist. 


3. Finden Sie heraus, welche IP-Adressen die Adbokis Buchclub GmbH 
mit Ihnen verknüpft. 


4. Beantragen Sie die Löschung Ihrer Telefonnummer. 


5. Lassen Sie sich nur den Datenfluss Ihres Vornamens zur Adbokis 
Buchclub GmbH anzeigen. (Bei JSON: Ein sequenzielles Anzeigen ist 
ausreichend) 
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G.3 Fragebögen 


Aufgaben im zweiten Teil 


1. 


Co Oo N A 


10. 


Finden Sie heraus, an welche Dritte die Adbokis Buchclub GmbH Ihre 
Daten weitergegeben hat. 


. Finden Sie heraus, von welchem Arbeitsplatzrechner der Adbokis Buch- 


club GmbH aus Ihre e-Mailadresse an die Extreme Advertisement Ltd. 
weitergegeben wurde. 


. Finden Sie heraus, fiir welchen Zweck die Adbokis Buchclub GmbH 


Thre Telefonnummer speichert. 


. Finden Sie heraus, durch wie viele Abteilungen Ihre e-Mailadresse 


geflossen ist. 


. Listen Sie auf, welche Datenkategorien auf dem Archivserver über Sie 


gespeichert sind. 


. Lassen Sie sich nur den Datenfluss der Rechnung anzeigen. 
. Exportieren Sie Ihre Daten. 
. Downloaden Sie Ihr Profilbild. 


. Beantragen Sie eine Änderung Ihrer IBAN. 


Setzen Sie die Darstellung auf den Ausgangszustand zurück. 


G.3 Fragebögen 


Der gesamte, über einen einzelnen Probanden gesammelte Datensatz bestand 
aus folgenden Teilen: 


1: 


2. 


Deckblatt mit Notizen und Informationen zur verwendeten Permutation 
(Abbildung G.1) 


Datenschutzerklärung (Abbildung G.2) 
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No 


. Protokoll der Bewertungen für den ersten Aufgabenteil zu PrivacyInsight, 


GenomSynlig und JSON (Abbildung G.3) 


. SUS für den ersten Aufgabenteil zu PrivacyInsight, GenomSynlig und 


JSON (Abbildung G.4) 


. Protokoll der Bewertungen fiir den zweiten Aufgabenteil (Abbildung G.5 


und G.6) 


. SUS fiir den zweiten Aufgabenteil (Abbildung G.4) 

. UEQ für den zweiten Aufgabenteil (Abbildung G.7 und G.8) 

. Fragebogen mit erweiterten Fragen (Abbildung G.9 bis G.11) 

. Fragebogen fiir die demographischen Angaben (Abbildung G.12 und 


G.13) 


Dazu kommen noch die Aufzeichnungen des Eye-Trackings. 


In den folgenden Abbildungen sind die Originaldokumente dargestellt. 
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G.3 Fragebögen 


Deckblatt 


Zeit: (YYYY-MM-DD, hh:mm) 


Versuchsleiter: (Name) 


Permutation Block 1 

0 1-2-3 0 1-3-2 O 2-1-3 
DO 2-3-1 0 3-1-2 O 3-2-1 
1 = Privacy Dashboard 


2 = Synlig 
3 = JSON-PDF 


Kommentare Versuchsteilnehmer 


Bemerkungen und Beobachtungen Versuchsleiter 


Abbildung G.1: Deckblatt 
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Datenschutzerklärung 


Im Rahmen der Studie „Privacy Dashboard“ werden personenbezogene Daten zum Zweck der 
Wissenschaft und Forschung gemäß den Bestimmungen des Bundesdatenschutzgesetzes erhoben, 
verarbeitet und genutzt. Die Teilnahme an der Studie ist freiwillig. 


Folgende personenbezogene Daten werden erhoben: 


> Teilnehmerliste 
o Name und Vorname 
o E-Mailadresse und ggf. Telefonnummer 
o Versuchszeitpunkt 
>  Versuchsdaten 
o  Zeitbedarf für Aufgabenstellungen im Versuchsablauf 
Antworten zu Aufgaben im Versuchsablauf 
Bewertungen und demografische Daten entsprechend des Versuchsfragebogens 
Trackingdaten des Blickverhaltens im Versuch 
Kommentare des Versuchsteilnehmers zum Versuchsablauf und zum Versuchsobjekt 


o0000o0 


Personenbezogene Daten werden ausschließlich beim Versuchsteilnehmer erhoben. Alle 
Versuchsdaten werden pseudonym erhoben und mit einem Zeitstempel versehen. Ein Personenbezug 
besteht einzig über Zeitstempel und die Teilnehmerliste (Zuordnungstabelle). 


Die Teilnehmerliste wird getrennt von den Versuchsdaten aufbewahrt. Nach Ende der Studie, jedoch 
spätestens nach einem Monat, wird die Teilnehmerliste gelöscht. 


Die Versuchsdaten werden anhand des Zeitstempels zusammengeführt. Nach Ende der Studie, jedoch 
spätestens nach einem Monat, werden die Zeitstempel aus den Versuchsdaten gelöscht. Die Daten 
sind ab diesem Zeitpunkt vollständig anonymisiert. Eine darüber hinausgehende Verarbeitung und 
Nutzung (insbesondere die Auswertung, Weitergabe und Veröffentlichung) findet nur auf Grundlage 
der anonymisierten Daten statt. 


Ich habe die Datenschutzerklärung gelesen und verstanden. 


Ort, Datum: Unterschrift: 


Ich willige in die Erhebung, Verarbeitung und Nutzung meiner 
personenbezogenen Daten zum Zweck der Wissenschaft und Forschung nach 
den Vorgaben und im Umfang der obigen Datenschutzerklärung ein. 


Ort, Datum: Unterschrift: 
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Abbildung G.2: Datenschutzerklärung 


G.3 Fragebögen 


Privacy Dashboard 


Aufgaben 


Finden Sie heraus, ob die Adbokis Buchclub GmbH in der Vergangenheit ein Bild von Ihnen bekommen 


hat. 
Lösung: Ja 
O gelöst D nicht gelöst 


Dauer: 


Finden Sie heraus, welche e-Mailadresse bei der Adbokis Buchclub GmbH von Ihnen hinterlegt ist. 


Lösung: Alice.Fox@Honigmail.de 
O gelöst D nicht gelöst 
Dauer: 
Finden Sie heraus, welche IP-Adressen die Adbokis Buchclub GmbH mit Ihnen verknüpft. 
Lösung: 217.146.191.19, 31.130.202.80 
O gelöst D nicht gelöst 
Dauer: 
Beantragen Sie die Löschung Ihrer Telefonnummer. 
Lösung: Klick auf Löschen Icon 
O gelöst D nicht gelöst 
Dauer: 
Lassen Sie sich nur den Datenfluss Ihres Vornamens zur Adbokis Buchclub GmbH anzeigen. 
Lösung: Selektieren des Datums 
O gelöst D nicht gelöst 


Dauer: 


Abbildung G.3: Protokoll für den ersten Aufgabenteil 
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Privacy Dashboard 


System Usability Scale 


Um das System zu bewerten, füllen Sie bitte den nachfolgenden Fragebogen aus. Er besteht aus Aussagen 
über das System. Abstufungen in der Übereinstimmung mit diesen Aussagen sind durch Kreise dargestellt. 
Durch Ankreuzen eines dieser Kreise können Sie Ihre Übereinstimmung mit einer Aussage äußern. 


Beispiel 


Ich fand das System unnötig bunt. O O O O ® 


Mit dieser Beurteilung sagen Sie aus, dass Sie der Aussage, das System sei unnötig bunt, gar nicht 
zustimmen. 


Entscheiden Sie möglichst spontan. Es ist wichtig, dass Sie nicht lange über die Aussagen nachdenken, 
damit Ihre unmittelbare Einschätzung zum Tragen kommt. 


Bitte kreuzen Sie immer eine Antwort an, auch wenn Sie bei der Einschätzung zu einer Aussage unsicher 
sind. Es gibt keine „richtige“ oder „falsche“ Antwort. Ihre persönliche Meinung zählt! 


Bitte geben Sie nun Ihre Einschätzung des Systems ab. Kreuzen Sie nur einen Kreis pro Zeile an. 


ne nicht zu 


neutral 


Ich stimme zu 


Ich 
Ich si 


Ich denke, dass ich das System gerne häufig benutzen würde. 
Ich fand das System unnötig komplex. 

Ich denke, das System war leicht zu benutzen. 

Ich glaube, ich würde die Hilfe einer fachkundigen Person 
benötigen, um das System benutzen zu können. 

Ich fand, die verschiedenen Funktionen in diesem System waren 


gut integriert. 
Ich denke, das System enthielt zu viele Inkonsistenzen. 


Ich kann mir vorstellen, dass die meisten Menschen den Umgang 
mit diesem System sehr schnell lernen. 
Ich fand das System sehr umständlich zu benutzen. 


Ich fühlte mich bei der Nutzung des Systems sehr sicher. 


o BS) CO ©) OMe o ie of 
o Ea o Ree ORS o Tel Of 
o kei OC Bee opa o ie Of 


o fe] opa OST o i) Of 
o BS) OC ©) Bei © o ie of 


Ich musste eine Menge lernen, bevor ich mit dem System arbeiten 
konnte. 
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Abbildung G.4: System Usability Scale 


G.3 Fragebögen 


Block 2 


Aufgaben 


Finden Sie heraus, an welche Dritte die Adbokis Buchclub GmbH Ihre Daten weitergegeben hat. 


Lösung: PayPal, Extreme Advertisement 
O gelöst D nicht gelöst 
Dauer: 


Finden Sie heraus, von welchem Arbeitsplatzrechner der Adbokis Buchclub GmbH aus Ihre e- 
Mailadresse an die Extreme Advertisement Ltd. weitergegeben wurde. 


Lösung: (Vertriebsabteilung) Workspace 23 
O gelöst D nicht gelöst 


Dauer: 


Finden Sie heraus, für welchen Zweck die Adbokis Buchclub GmbH Ihre Telefonnummer speichert. 


Lösung: Kundenservice/-betreuung 
O gelöst D nicht gelöst 
Dauer: 
Finden Sie heraus, durch wie viele Abteilungen Ihre e-Mailadresse geflossen ist. 
Lösung: 2 (Vertrieb, Kundenbetreuung) 
O gelöst D nicht gelöst 
Dauer: 
Listen Sie auf, welche Datenkategorien auf dem Archivserver über Sie gespeichert sind. 


Lösung: Lieferadresse, Nachname, Vorname, e-Mailadresse, Lieferadresse, Rechnung, 
Wohnsitzstaat 


O gelöst D nicht gelöst 
Dauer: 
Lassen Sie sich nur den Datenfluss der Rechnung anzeigen. 
Lösung: Selektieren des Datensatzes 
O gelöst D nicht gelöst 


Dauer: 
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Abbildung G.5: Protokoll für den zweiten Aufgabenteil (S. 1) 


437 


G Ablauf, Aufgaben und Fragebögen der Nutzerstudie 


Block 2 


Aufgaben 


Exportieren Sie Ihre Daten. 
Lösung: Klick in der Menüleiste 
O gelöst D nicht gelöst 
Dauer: 

Downloaden Sie Ihr Profilbild. 
Lösung: Klick aufs Icon 
D gelöst D nicht gelöst 
Dauer: 

Beantragen Sie eine Änderung Ihrer IBAN. 
Lösung: Klick aufs Icon 
D gelöst D nicht gelöst 
Dauer: 

Setzen Sie die Darstellung auf den Ausgangszustand zurück. 
Lösung: Klick in der Menüleiste 
D gelöst D nicht gelöst 


Dauer: 
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Abbildung G.6: Protokoll fiir den zweiten Aufgabenteil (S. 2) 


438 


G.3 Fragebögen 


Block 2 


User Experience Questionnaire 
Um das System zu bewerten, füllen Sie bitte den nachfolgenden Fragebogen aus. Er besteht aus 
Gegensatzpaaren von Eigenschaften, die das System haben kann. Abstufungen zwischen den Gegensätzen 
sind durch Kreise dargestellt. Durch Ankreuzen eines dieser Kreise können Sie Ihre Zustimmung zu einem 
Begriff äußern. 


Beispiel 
attraktiv © ® O O O O O  unattraktiv 
Mit dieser Beurteilung sagen Sie aus, dass Sie das System eher attraktiv als unattraktiv 
einschätzen. 


Entscheiden Sie möglichst spontan. Es ist wichtig, dass Sie nicht lange über die Begriffe nachdenken, damit 
Ihre unmittelbare Einschätzung zum Tragen kommt. 


Bitte kreuzen Sie immer eine Antwort an, auch wenn Sie bei der Einschätzung zu einem Begriffspaar 
unsicher sind oder finden, dass es nicht so gut zum System passt. 


Es gibt keine „richtige“ oder „falsche“ Antwort. Ihre persönliche Meinung zählt! 


Seite 1 von 2 


Abbildung G.7: User Experience Questionnaire (S. 1) 
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unerfreulich 
unverständlich 
kreativ 

leicht zu lernen 
erfrischend 
langweilig 
uninteressant 
unberechenbar 
schnell 

neu 
unbedienbar 
gut 

kompliziert 
abstoßend 
veraltet 
unangenehm 
vorhersagbar 
abwechslungsreich 
zuverlässig 
ineffizient 
übersichtlich 
stockend 
aufgeräumt 
schön 
sympathisch 


unauffällig 


Block 2 


User Experience Questionnaire 


N 


o ge ES EA O Be EA OC Bey O Fey O Fe) O Te EA O o 
o fey o Rey o Be) o Fel o Bey O Be] O ey O Fey O Bel O Bel O Fe O fe) CO Fe 
o Hey o fe) o Re] o Fel Oo Be o Re) CO Be) O Fey O Re) O Rey o He O Fe O Fe 
ion ga © Oo © Bek EA © Mel © O © Rel © Rey © Rey © O © O © O © > 
o ©) o © o © o © o © Bel © o © Oo © o © o © o © o © o © 
o ke o © o © o © ek © Mek © o © o © 0 © © © o © o © © © 


N 


o ker o Re] O Re) O Fel Oo Be) Oo Hei Oo EA EA EA Eol EA O fe 


erfreulich 
verstandlich 
phantasielos 
schwer zu lernen 
einschläfernd 
spannend 
interessant 
voraussagbar 
langsam 

alt 

bedienbar 
schlecht 
einfach 
anziehend 
modern 
angenehm 
unvorhersagbar 
eintönig 
unzuverlässig 
effizient 
verwirrend 
flüssig 
überladen 
hässlich 
unsympathisch 


auffällig 
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Abbildung G.8: User Experience Questionnaire (S. 2) 


G.3 Fragebögen 


Block 2 


Erweiterte Fragen 


Füllen Sie bitte den nachfolgenden ergänzenden Fragebogen aus. 


Entscheiden Sie möglichst spontan. Es ist wichtig, dass Sie nicht lange über die Aussagen nachdenken, 
damit Ihre unmittelbare Einschätzung zum Tragen kommt. 


Bitte kreuzen Sie immer eine Antwort an, auch wenn Sie bei der Einschätzung zu einer Aussage unsicher 
sind. Es gibt keine „richtige“ oder „falsche“ Antwort. Ihre persönliche Meinung zählt! 


Insgesamt würde ich die Nutzerfreundlichkeit des Systems „Privacy Dashboard“ wie folgt bewerten: 


Soi ae Schrecklich Gering Okay Gut Exzellent bests 
möglich möglich 
O oO O O O O O 


Sind die im Privacy Dashboard zusätzlich verfügbaren Informationen die gesteigerte Komplexität im 
Vergleich zu Synlig wert? 


Ganz undgar nicht O O O O © O O  Vollkommen 


Halten Sie die Integration von Datenschutzauskunft und weiteren Betroffenenrechten (Löschung, 
Berichtigung) in einer Benutzeroberfläche für sinnvoll? 


Ganzundgarnicht O O O O O O O Vollkommen 


Welche Informationstiefe würden Sie im Datenflussgraph für personenbezogene Daten im Rahmen 
einer Auskunft nach § 34 Bundesdatenschutzgesetz erwarten? 


Nur Erhebungs- und Übermittlungsvorgänge 

Datenflüsse zu Auftragsdatenverarbeitern 

Datenfliisse zwischen Abteilungen (einschließlich Auftragsdatenverarbeitern) 
Datenflüsse zwischen einzelnen IT-Systemen 

Datenflüsse in IT-Systemen zwischen Applikationen und Speicherbereichen 
Ich halte Informationen zu Datenflüssen grundsätzlich für unnötig 

Weiß nicht 


o000000 
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Abbildung G.9: Erweiterte Fragen (S. 1) 
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Block 2 


Erweiterte Fragen 
Unlinkability 


Unlinkability (Deutsch: Unverkettbarkeit) misst, wie viel besser Abteilungen in der Adbokis Buchclub 
GmbH dadurch, dass sie Zugriff auf die für die Auskunft gesammelten Informationen haben, über die 
Zusammenhänge zwischen Ihnen, Ihren Daten und den Orten der Datenverarbeitung Bescheid wissen 
(relative Metriken). Im Privacy Dashboard sehen sie vier verschiedene Metriken für Unlinkability: 


- Ganz auf der linken Seite eine Speicher- und Verarbeitungsmetrik D-=. Sie beschreibt, wie viel 
Abteilungen in der Adbokis Buchclub GmbH über die Organisationseinheiten und IT-Systeme in 
denen Ihre Daten verarbeitet und gespeichert werden, wissen. 

-  Links-mittig eine Datenflussmetrik 20>Q. Sie charakterisiert, wie viel Abteilungen in der Adbokis 
Buchclub GmbH über die Herkunft Ihrer Daten, die Weitergabe Ihrer Daten zwischen 
Organisationseinheiten und IT-Systemen und die Übermittlung Ihrer Daten an andere 
Unternehmen wissen. 

-  Rechts-mittig eine Verknüpfungsmetrik D}-D. Sie kennzeichnet, wie gut Abteilungen in der Adbokis 
Buchclub GmbH feststellen können, ob zwei Datensätze zur gleichen Person gehören. 

- Ganz rechts eine Identifikationsmetrik D-#. Sie legt offen, wie gut Abteilungen in der Adbokis 
Buchclub GmbH Daten Ihnen als Person zuordnen können. 

- Beispielsweise bedeutet eine Identifikationsunlinkability von 80%, dass Abteilungen in der Adbokis 
Buchclub GmbH 80% der Informationen durch die Auskunft nicht bekommen haben, die sie vor 
Installation eines Auskunftssystems noch gebraucht hätten, um jede Zuordnung offen zu legen. Auf 
der anderen Seite bedeutet dies aber auch, dass Sie für das Unternehmen um 20% transparenter 
geworden sind. 


Die Angabe der Unlinkability gibt Ihnen als Betroffenem der Datenverarbeitung die Möglichkeit 
zwischen den Vorteilen abzuwägen, die Ihnen das Privacy Dashboard bietet (Transparenz über die 
Datenflüsse, Einblick in die Daten, Löschung und Berichtigung) und dem Nachteil, dass sie auch für das 
datenverarbeitende Unternehmen transparenter werden. 


Deshalb können sie durch Klick auf den entsprechenden Button im Privacy Dashboard bestimmen, dass 
Sie in Zukunft auf eine Nutzung des Privacy Dashboards verzichten wollen. Eine Datensammlung zum 
Zweck der Auskunft findet dann nicht mehr statt. 
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Abbildung G.10: Erweiterte Fragen (S. 2) 


G.3 Fragebögen 


Block 2 


Erweiterte Fragen 
Haben Sie das Konzept von Unlinkability verstanden? 


O Ja 
O Nein 
O Weiß nicht 


Halten Sie die angezeigten Unlinkabilitymetriken für hilfreich? 


O Ja 
O Nein 
O Weiß nicht 


Würden Sie aufgrund der gegebenen Unlinkability (76%, 80%, 86%, 89% - Erläuterung siehe oben) in 
Zukunft lieber auf die Nutzung eines Privacy Dashboards verzichten? 


O Ja 

O Nein 

© Unentschieden 
O Weiß nicht 


Wer ist Ihrer Meinung nach fiir den Schutz von personenbezogenen Daten verantwortlich? 


Bitte vergleichen sie paarweise. 


1 2 3 4 5 6 7 
DerStat O O O O O O O  DerBürger 
Die Unternehmen O O O O O O O DerStaat 
DieKunden O O O O O O O Die Unternehmen 


Ich bin mir bei meinen Einschätzungen über alle Fragebögen hinweg... 


Vollkommen unsicher O O O O O O O Sehrsicher 
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G Ablauf, Aufgaben und Fragebögen der Nutzerstudie 


Demografische Angaben 


Bitte beantworten Sie uns noch einige letzte Fragen zu Ihrer Person. Die Angaben dienen rein statistischen 
Zwecken. Wir versichern Ihnen, dass wir alle Angaben nur in anonymisierter Form auswerten werden. 


Welches Geschlecht haben Sie? 


O Weiblich 
© Männlich 
O Keine Angabe 


Wie alt sind Sie? 


14-19 Jahre 
20-29 Jahre 
30-39 Jahre 
40-49 Jahre 
50-59 Jahre 
60-69 Jahre 
70 und älter 
Keine Angabe 


oO0O000000 


Welchen höchsten Schulabschluss haben Sie? 


© Sonderschulabschluss, Abschluss der Förderschule 

© Volks- oder Hauptschulabschluss / Polytechnische Oberschule 8. Klasse 
O Mittlere Reife (Realschulabschluss, Polytechnische Oberschule 10. Klasse) 
© Fachhochschulreife, Abitur, Erweiterte Oberschule 

O Abgeschlossenes Studium 

O Weiß nicht 

O Keine Angabe 


Sollten Sie einen ausländischen Schulabschluss haben, so versuchen Sie bitte diesen einem der 
deutschen Bildungsabschlüsse zuzuordnen. 


Was machen Sie derzeit hauptsächlich? 


Erwerbstätig (auch selbstständig) 

In Ausbildung, Schule, Umschulung, Studium, Wehr-/Zivildienst 
Rentner, Pensionär, Vorruhestand 

Hausmann/-frau, Elternzeit, Mutterschutz 

Zurzeit arbeitslos 

Keine Angabe 


o0o0000 
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Abbildung G.12: Demographische Angaben (S. 1) 
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G.3 Fragebögen 


Demografische Angaben 


Wie würden Sie Ihre Wohngegend einordnen? 
Ist sie... 


Großstädtisch (> 100 000 Einwohner) und Einzugsbereich 
Städtisch (> 20 000 Einwohner) 

Kleinstädtisch 

Ländlich geprägt 

Weiß nicht 

Keine Angabe 


o0o0000 


Wenn Sie technische Probleme mit beispielsweise Ihrem PC oder Handy haben, können Sie diese... 


Fast immer selbst lösen 
Manchmal selbst lösen 
Fast niemals selbst lösen 
Weiß nicht 

Keine Angabe 


o0000 


Welche Erfahrung haben Sie mit Webanwendungen (Software, die über einen Webbrowser angezeigt 
und bedient wird)? 


Ich habe bereits selbst Webanwendungen programmiert 
Ich nutze regelmäßig Webanwendungen 

Ich nutze gelegentlich Webanwendungen 

Ich weiß nicht, was Webanwendungen sind 

Keine Angabe 


oOo000 


Haben Sie bereits selbst ein Auskunftsgesuch nach § 34 Bundesdatenschutzgesetz gestellt? 


Schon mehrmals 
Einmalig 

Noch nie 

Weiß nicht 
Keine Angabe 


o0o000 
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Abruf 


Abruf ist der Bezug personenbezogener Daten per Dateniibertragung 
durch einen Empfänger. Die weitergebende Stelle sorgt gegebenenfalls 
für die notwendigen technischen Voraussetzungen, wird jedoch nicht 
selbst aktiv. Weitergabe an einen Empfänger und Abruf durch einen 
Empfänger sind in ihren Rechtsfolgen gleich. 


(Datenschutz-)Auskunftsplattform 


Die Benutzeroberfläche, auf der dem Betroffenen eine Auskunft präsen- 
tiert wird. Eine Auskunftsplattform hat im Regelfall interaktive Elemente 
zur Änderung von Datenschutzvoreinstellungen oder der Wahrnehmung 
von Betroffenenrechten. Das englischsprachige Synonym für eine Aus- 
kunftsplattform ist Privacy Dashboard. Die in dieser Arbeit entwickelte 
Auskunftsplattform heißt PrivacyInsight. 


Auswerten 


Auswerten ist das Erzeugen neuer personenbezogener Daten mit eigener 
Aussagekraft über den Betroffenen aus bestehenden personenbezogenen 
Daten, insbesondere die Berechnung von Scorewerten und die automati- 
sierte Einzelentscheidung. Dabei können auch nicht-personenbezogene 
Daten in die Auswertung einfließen. 


Daten 


Daten sind nach einer festgelegten Syntax gebildete Zeichenketten. Daten 
sind nicht zwingend körperlich. 
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Datenschutzauskunftssystem 


Ein System, das die fiir eine Datenschutzauskunft erforderlichen In- 
formationen automatisiert sammelt und dem Betroffenen auf Anfrage 
bereitstellt. 


Einsichtnahme 


Erheb 


Einsichtnahme ist die höchstpersönliche Betrachtung personenbezogener 
Daten durch den Empfänger. Die Einsichtnahme muss nicht optisch, 
sondern kann auch akustisch oder haptisch erfolgen. Sie unterscheidet 
sich vom Abruf durch den Medienbruch. Eine Verarbeitung der eingese- 
henen personenbezogenen Daten durch den Empfänger ist nicht ohne 
weiteres möglich, sondern erfordert eine vorhergehende Erfassung. 


en 


Erheben ist nach $ 3 Abs. 3 BDSG das „Beschaffen von [personen- 
bezogenen] Daten über den Betroffenen.“ Die Erhebung kann beim 
Betroffenen selbst oder bei einem Dritten stattfinden. 


Informationen 


Informationen sind Daten gemeinsam mit ihrer Semantik. 
Personenbezogene Daten im Sinne des Datenschutzgesetzes sind Infor- 
mationen. Insofern werden Daten und Informationen vielfach synonym 
verwendet. Die Legaldefinition personenbezogener Daten wird in Kapitel 
3.7.1 diskutiert. 


Löschen 


448 


Löschen ist nach § 3 Abs. 4 S. 2 Nr. 5 BDSG das ,,Unkenntlichmachen 
gespeicherter personenbezogener Daten.“ Löschen ist keine Verarbeitung 
i.e. S., da personenbezogene Daten nicht Teil der Eingabe oder der Ausga- 
be des Löschvorgangs sind. Die Löschung hat keine personenbezogenen 
Daten zum Ergebnis. 
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Nutzung 


Die Nutzung ist ein Auffangtatbestand im BDSG. Die Nutzung ist nach 
§ 3 Abs. 5 BDSG „jede Verwendung personenbezogener Daten, soweit 
es sich nicht um Verarbeitung handelt.“ 


Nutzungskontrolle 


Nutzungskontrolle (engl. Usage Control (UC)) bezeichnet Verfahren, 
die steuern, unter welchen Umständen Zugriff auf Daten gewährt wird 
und wie nachfolgend mit den Daten umgegangen werden darf. Nut- 
zungskontrolle kann als eine Erweiterung von Access-Control über den 
Zugriffszeitpunkt hinaus betrachtet werden. 


Personenbezogene Daten 


Personenbezogene Daten sind nach $ 3 Abs. 1 BDSG „Einzelangaben 
über persönliche und sachliche Verhältnisse einer bestimmten oder 
bestimmbaren natürlichen Person (Berroffener).‘“ Der komplexe Begriff 
der personenbezogenen Daten wird im Detail in Kapitel 3.7.1 diskutiert. 


(Ereignis-)Protokoll 


Ein (Ereignis-)Protokoll ist die A-posteriori-Aufzeichnung und Doku- 
mentation von Ereignissen in IT-Systemen und Organisationen, die 
personenbezogene Daten verwenden. Ein Protokoll ist vorgangsbezogen. 
Ein Protokoll umfasst (1) den Zeitpunkt und die Reihenfolge der Ereig- 
nisse, (2) die Ereignisse selbst und (3) deren Verursacher. Verursacher 
sind beteiligte Personen und andere Akteure sowie technische Systeme. 
Ein Protokoll kann in einer Protokolldatei (auch: Logdatei) gespeichert 
werden. 

In Abgrenzung dazu ist ein Kommunikationsprotokoll die A-priori- 
Festlegung von Ablauf, Syntax, und Semantik eines Kommunikations- 
vorgangs. 
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(Data-) Provenance 


Data-Provenance ist die dokumentierte Ableitungshistorie eines Datums, 
ausgehend von seiner urspriinglichen Quelle. Provenance gibt Auskunft 
über die Herkunft von Daten sowie über die Erzeugung von Daten aus 
anderen Daten. Während ein Protokoll vorgangsbezogen ist, ist Proven- 
ance datenbezogen. Die Data-Provenance fiir die personenbezogenen 
Daten eines Betroffenen wird als Personal-Data-Provenance bezeichnet. 


Speichern 


Speichern ist nach § 3 Abs. 4 S. 2 Nr. 1 BDSG das ,,Aufbewahren 
personenbezogener Daten auf einem Datenträger zum Zwecke ihrer 
weiteren“ Verwendung. 


Sperren 


Sperren ist nach $ 3 Abs. 4 S. 2 Nr. 4 BDSG das „Kennzeichnen 
gespeicherter personenbezogener Daten, um ihre weitere Verarbeitung 
oder Nutzung einzuschränken.“ Sperren ist keine Verarbeitung i.e. S., 
da personenbezogene Daten nicht verändert, sondern nur ergänzende 
Metadaten hinzugefügt werden. 


System 
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Ein System ist allgemein eine Menge von Entitäten oder Komponenten 
gemeinsam mit den Beziehungen zwischen diesen. Ein System entsteht 
dadurch, dass es operiert und sich gegenüber seiner Umgebung durch Ex- 
klusivität abgrenzt. So allgemein wie der Systembegriff ist, so vielfältig 
wird er auch verwendet. Im Provenance-Systemmodell ist ein System eine 
Ansammlung technischer (z. B. ein Cluster) oder organisatorischer (z.B. 
eine Abteilung) Entitäten, denen ein gemeinsames Wissen unterstellt 
wird. Interne Datenflüsse und verarbeitete Daten sind allen beteiligten 
Entitäten bekannt. Sofern eine Ansammlung organisatorischer Entitäten 
gemeint ist, entspricht der Systembegriff dem organisatorischen Stellen- 
begriff. Der Umfang eines Systems legt den Verantwortungsbereich der 


Glossar 


UC- und Provenance-Komponenten fest. Im Angreifermodell ist ein Sys- 
tem ©” ein Modell der Menge aller Entitäten, mit denen der Angreifer 
in Interaktion treten kann. Ein /T-System ist jedes datenverarbeitende 
technische Gerät, das von anderen Systemen, beispielsweise über eine 
IP-Adresse, adressierbar ist. Ein IT-System kann auch virtualisiert sein. 


Übermitteln 


Übermitteln ist nach $ 3 Abs. 4 S. 2 Nr. 3 BDSG die Weitergabe 
personenbezogener Daten an einen Dritten oder die Einsichtnahme oder 
der Abruf personenbezogener Daten durch einen Dritten. 


Umgang 


Umgang ist die Erhebung, Verarbeitung und Nutzung personenbezogener 
Daten. 


(Grad der) Unverkettbarkeit 


Der Grad der Unverkettbarkeit ist die Unsicherheit eines Angreifers A 
über die wahre Verkettungsrelation in einer Menge von Kandidatenre- 
lationen R im Gesamtsystem ©”, nachdem das Beobachtungsereignis 
I eingetreten ist, im Vergleich zur Unsicherheit mit seinem vorherigen 
Wissensstand. 


Verändern 


Verändern ist nach $ 3 Abs. 4 S. 2 Nr. 2 BDSG die Modifikation, das 
„inhaltliche Umgestalten gespeicherter personenbezogener Daten.“ 


Verarbeitung 


Nach § 3 Abs. 4 S. 1 BDSG ist Verarbeitung jedes „Speichern, Verändern, 
Übermitteln, Sperren und Löschen personenbezogener Daten.“ Die 
Verwendung des Begriffs „Verarbeitung“ in der DSRL ist extensiver und 
entspricht dem Begriff des Umgangs im Bundesdatenschutzgesetz. 

Der Begriff der Verarbeitung personenbezogener Daten im BDSG ist 
unglücklich definiert. Zum einen umfasst er nicht alles, was landläufig 
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unter Verarbeitung verstanden wird (Auswertung, insb. die automatisierte 
Einzelentscheidung), zum anderen nimmt er die in ihrer Qualität anderen 
Tatbestände der Speicherung und Übermittlung mit auf. Dadurch erzeugt 
er eine begriffliche Asymmetrie. Die Übermittlung an Dritte und die 
Erhebung von Dritten stehen einander gleichberechtigt gegenüber. Der 
eine Tatbestand ist jedoch Teil der Verarbeitung, der andere nicht. 
Weitergabevorgänge innerhalb einer verantwortlichen Stelle sind ebenso 
keine Verarbeitung. Deshalb wird in den Kapiteln 4 bis 9 der sauber 
abgegrenzte Begriff der Verarbeitung i. e. S. verwendet. 


Verarbeitung i. e. S. 


Die Verarbeitung im engeren Sinne bezeichnet die Veränderung und 
Auswertung (algorithmische Informationsverarbeitung) von personenbe- 
zogenen Daten in Prozessen, die Speicherung der Daten zur sofortigen 
Weiterverarbeitung in dem einem Prozess zugewiesenen Teil des Ar- 
beitsspeichers und dem flüchtigen Speicher (Register und Cache) eines 
Prozessors sowie die Aufbereitung der Daten für die Einsichtnahme 
durch den Benutzer über eine Benutzerschnittstelle, für die Weitergabe, 
für den Abruf oder für die dauerhafte Speicherung. Die Speicherung zur 
dauerhaften Aufbewahrung, auch im Arbeitsspeicher (RAM-Disk), ist 
nicht Teil der Verarbeitung i. e. S. 


Veröffentlichung 


Eine Veröffentlichung ist das Bereithalten personenbezogener Daten 
zum Abruf oder zur Einsicht durch eine nicht klar abgegrenzte Perso- 
nengruppe. 


Verwendung 
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Verwendung ist jeder Umgang mit personenbezogenen Daten mit Aus- 
nahme der Erhebung. 
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Umgang 
(95/46/EG: 
Verarbeitung) 


Verwendung 


| Auswerten 


a 


Abbildung: Begriffshierarchie Datenschutz! 


Weitergabe 


Weitergabe ist die Ubertragung personenbezogener Daten von einer 
Stelle auf eine andere Person oder Stelle. Die interne Weitergabe ist 
die Weitergabe zwischen Personen oder Stellen, die einer gemeinsa- 
men verantwortlichen Stelle zuzuordnen sind. Gemeint ist jede Form 
von Ubertragung: Miindliche oder fernmiindliche Mitteilung, schrift- 
liche Ubersendung, drahtgebundene oder drahtlose Dateniibertragung, 
Übergabe oder Übersendung eines Datenträgers.? 


! Legende: DJ] Übergeordneter Sammelbegriff im BDSG; C] der Begriff wird in $ 3 BDSG 
in einem eigenen Absatz definiert; C] der Begriff wird in § 3 BDSG untergeordnet definiert; 
C] der Begriff wird im BDSG verwendet; į =! der Begriff wird im BDSG nicht verwendet; 
|) der Vorgang wird durch das implementierte Provenance-Tracking erfasst; A—+B A ist im 
rechtlichen Sinne B; A—>B A kann im technischen Sinne B sein; A- ->B A ist in dieser Arbeit 
als B definiert. 

2 Dammann in: Simitis, BDSG 2014, $ 3 Rn. 146. 
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